Certified Kubernetes Application Developer CKAD CKAD Questions 526–600 | Page 8/12

526

MCQhard

You apply the following NetworkPolicy: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress After applying, pods in the namespace cannot reach the kube-dns service. What is the most likely reason?

A.The policy does not have a namespaceSelector

B.The policy blocks all egress traffic, including DNS

C.The policy blocks all ingress traffic only

D.The kube-dns service is not running

AnswerB

The policy defines no egress rules (an empty `egress` list), which by NetworkPolicy semantics means all egress traffic is denied — including DNS queries sent over UDP port 53 to the kube-dns service. Even if other services are reachable within the cluster, the inability to resolve DNS names will cause most network communication to fail, making this the primary reason the pod cannot connect. Ingress is also blocked, but the DNS failure is exclusively an egress-side issue.

Why this answer

The NetworkPolicy explicitly includes `Egress` in `policyTypes` and uses an empty `podSelector: {}`, which selects all pods in the namespace. With no `egress` rules defined, the default behavior is to deny all egress traffic. DNS resolution for kube-dns typically uses UDP/TCP on port 53, and since all egress traffic is blocked, pods cannot reach the kube-dns service, causing DNS failures.

Exam trap

The trap here is that candidates often assume a NetworkPolicy with no rules allows all traffic, but in Kubernetes, an empty `podSelector: {}` combined with `policyTypes` that list a direction (Ingress/Egress) actually defaults to denying all traffic in that direction, which is the opposite of what many expect.

How to eliminate wrong answers

Option A is wrong because a `namespaceSelector` is not required for this policy; the `podSelector: {}` already selects all pods in the namespace, and the policy correctly applies to the namespace where it is created. Option C is wrong because the policy includes both `Ingress` and `Egress` in `policyTypes`, so it blocks both ingress and egress traffic, not just ingress. Option D is wrong because the question states that after applying the policy, pods cannot reach kube-dns, implying the service was running before; the issue is caused by the network policy, not the service's availability.

Full explanation →

527

Multi-Selecthard

Which THREE components are typically involved when using Ingress to expose a service?

Select 3 answers

A.Ingress resource

B.External load balancer

C.Ingress controller

D.NetworkPolicy

E.Service

AnswersA, C, E

The Ingress resource is a declarative Kubernetes API object that defines external HTTP(S) routing rules, typically matching requests by hostname and URL path to specific backend Services. It serves only as a specification; it does not perform any traffic forwarding itself. Once created, an Ingress controller watches and converts these rules into actual proxy configurations. Without this resource, there is no desired state for the controller to enforce.

Why this answer

An Ingress resource defines the routing rules for external HTTP/HTTPS traffic to services within the cluster. It specifies hostnames, paths, and the backend service to forward requests to, but it is only a configuration object. The actual traffic handling requires an Ingress controller (e.g., NGINX, Traefik) to process the Ingress resource and implement the rules, and a Service of type ClusterIP or NodePort to expose the target pods internally.

Exam trap

The CKAD exam often tests the misconception that an external load balancer is a mandatory component of Ingress, when in fact the Ingress controller itself can run as a pod within the cluster and does not require an external LB unless the controller's Service type is LoadBalancer.

Full explanation →

528

MCQeasy

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.

AnswerD

Container logs are the most direct source of information about what the application was doing when the liveness probe failed, because the application often writes an error, panic, or timeout message immediately before it becomes unresponsive. Use `kubectl logs <pod>` to view the current logs, and `kubectl logs <pod> --previous=true` if the container has been restarted, to find logs from the failed run. Correlating log timestamps with probe failure events from `kubectl describe` lets you pinpoint the exact code path or dependency failure causing the probe to fail.

Why this answer

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.

Exam trap

The trap here is that candidates assume the liveness probe failure is a network or configuration issue (options A, B, C) rather than recognizing that intermittent failures are almost always an application-level problem best diagnosed via container logs.

How to eliminate wrong answers

Option A is wrong because 'kubectl describe pod' shows probe events (e.g., 'Liveness probe failed: HTTP probe failed with statuscode: 503') but only reports the failure itself, not the application's internal state or the reason for the failure. Option B is wrong because testing network connectivity from another pod (e.g., via 'kubectl exec' and curl) checks network-level reachability, but the probe is failing intermittently, not due to a network partition; the issue is likely application-level. Option C is wrong because increasing failureThreshold only masks the symptom by allowing more failures before restart, without diagnosing or fixing the underlying intermittent problem.

Full explanation →

529

MCQmedium

A Role named 'pod-reader' in namespace 'ns1' grants get, list, and watch on pods. Which RoleBinding correctly binds this role to a ServiceAccount 'sa1' in the same namespace?

A.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

B.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: User name: sa1

C.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

D.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: default

AnswerA

This is correct because a RoleBinding in ns1 uses roleRef to bind the namespaced Role 'pod-reader' to ServiceAccount 'sa1' also in ns1. RoleBindings are namespaced, and both the Role and the ServiceAccount must reside in the same namespace as the binding for the permissions to apply. Here the subject kind is ServiceAccount, which matches the intended identity, so sa1 will receive the Role's permissions.

Why this answer

A RoleBinding in the same namespace as the Role and ServiceAccount must specify the Role's kind as 'Role' (not ClusterRole) and include the ServiceAccount's namespace in the subjects list. The roleRef references the 'pod-reader' Role with the correct apiGroup and kind, and the subject specifies the ServiceAccount 'sa1' in namespace 'ns1', which matches the Role's namespace, allowing the binding to grant the permissions.

Exam trap

The trap here is that candidates often forget to include the ServiceAccount's namespace in the subjects list or mistakenly use 'kind: User' for a ServiceAccount, leading to a binding that either fails or applies to the wrong entity.

How to eliminate wrong answers

Option B is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount', and a ServiceAccount cannot be bound via a User subject; the subject must match the actual entity type. Option C is wrong because it uses 'kind: ClusterRole' in the roleRef, but the question specifies a Role (namespaced), not a ClusterRole; a RoleBinding can only reference a Role in the same namespace or a ClusterRole (which would then be scoped to the namespace), but here the role is a Role, so the kind must be 'Role'. Option D is wrong because it specifies 'namespace: default' in the subject, but the ServiceAccount 'sa1' is in namespace 'ns1', so the subject's namespace must match the ServiceAccount's actual namespace for the binding to work.

Full explanation →

530

MCQhard

An Ingress resource is configured with TLS termination. The secret referenced in the Ingress is present, but the Ingress controller returns 404. What is the most likely cause?

A.The IngressClass annotation is missing

B.The Ingress controller is not installed

C.The backend Service does not have any endpoints

D.The TLS certificate is expired

AnswerC

The Ingress controller dynamically discovers the backend Service's endpoints (via EndpointSlices) and configures its proxy to forward traffic to those IPs. If the Service selector matches no pods or the pods are not Ready, the endpoint list is empty, leaving no upstream target for the proxy to route to; the controller therefore responds with HTTP 404 for that host/path. This is a classic cause of '404 Not Found' even when Ingress and Service definitions appear valid, so checking `kubectl get endpoints <service>` is the standard diagnostic step.

Why this answer

When an Ingress returns a 404 error despite TLS being configured and the secret present, the most common cause is that the backend Service has no healthy endpoints. The Ingress controller routes traffic to the Service's endpoints (pods), and if none are ready (e.g., due to failed readiness probes or scaled-to-zero replicas), the controller has no target to forward requests to, resulting in a 404 response.

Exam trap

Candidates often assume that a 404 error with TLS configured indicates a certificate or secret issue, but in Kubernetes, the Ingress controller returns a 404 when the backend Service lacks ready endpoints.

How to eliminate wrong answers

Option A is wrong because the IngressClass annotation is used to specify which Ingress controller should process the resource; its absence would cause the Ingress to be ignored entirely, not a 404 after TLS termination. Option B is wrong because if the Ingress controller were not installed, the Ingress resource would have no effect at all, and the 404 would likely come from a default backend or no route at all, not from TLS-terminated traffic. Option D is wrong because an expired TLS certificate would cause TLS handshake errors (e.g., certificate expired in browser or curl), not a 404 HTTP status code, which is an application-layer response after the TLS connection is established.

Full explanation →

531

MCQhard

A Deployment named 'web' has replicas: 3 and update strategy type: Recreate. You run 'kubectl set image deployment/web web=nginx:1.22'. What immediate effect will this have on the existing pods?

A.One pod is terminated, then a new pod is created, repeating until all are updated.

B.The command fails because Recreate does not support image updates.

C.All existing pods are terminated simultaneously, then new pods are created.

D.The pods are updated in place without termination.

AnswerC

With the Recreate update strategy, the Deployment controller first terminates all existing Pods from the old ReplicaSet, then creates the new Pods from the updated ReplicaSet. For replicas: 3, all three old Pods are shut down before any new Pod is scheduled, resulting in a complete but brief period of unavailability. This is the correct behavior of Recreate.

Why this answer

The Deployment's update strategy type is set to 'Recreate', which means all existing pods are terminated simultaneously before any new pods are created. When you run 'kubectl set image deployment/web web=nginx:1.22', it triggers a rollout that follows the Recreate strategy: first, all current pods are deleted, then the new pods are created with the updated image. This is in contrast to the RollingUpdate strategy, which updates pods gradually.

Exam trap

The trap here is that candidates often confuse the Recreate strategy with a rolling update, assuming pods are updated one by one, or mistakenly think Recreate prevents image updates entirely.

How to eliminate wrong answers

Option A is wrong because it describes a rolling update behavior (one pod at a time), which is characteristic of the RollingUpdate strategy, not Recreate. Option B is wrong because Recreate does support image updates; the strategy simply dictates how the update is performed, not whether it is allowed. Option D is wrong because pods are not updated in place; Kubernetes always terminates and recreates pods when the image changes, regardless of the update strategy.

Full explanation →

532

MCQhard

You have an Ingress resource with TLS configured. The certificate is stored in a Secret named 'my-tls'. Which field in the Ingress YAML specifies the Secret name?

A..spec.tls[0].secretName

B..spec.tls[0].secret

C..metadata.annotations['cert-manager.io/cluster-issuer']

D..spec.tlsSecretName

AnswerA

In the Ingress v1 API, TLS is defined under spec.tls as a list. Each list element is an object that includes a secretName field, which is the exact key that references an existing Kubernetes Secret in the same namespace as the Ingress. That Secret must contain the TLS certificate and private key under the standard keys tls.crt and tls.key. This is the canonical way to attach an existing certificate to an Ingress.

Why this answer

In Kubernetes Ingress resources, the TLS configuration is defined under `.spec.tls`, which is an array of TLS objects. Each object contains a `hosts` field and a `secretName` field that references the Kubernetes Secret holding the TLS certificate and private key. Option A correctly identifies `.spec.tls[0].secretName` as the field that specifies the Secret name.

Exam trap

The trap here is that candidates confuse the `secretName` field with a non-existent `secret` field, or mistakenly think the TLS Secret is specified at the top level of the Ingress spec rather than under the `tls` array.

How to eliminate wrong answers

Option B is wrong because `.spec.tls[0].secret` is not a valid field; the correct field name is `secretName`. Option C is wrong because `metadata.annotations['cert-manager.io/cluster-issuer']` is an annotation used by cert-manager to specify the ClusterIssuer for automatic certificate provisioning, not a field that directly references the Secret name. Option D is wrong because `.spec.tlsSecretName` is not a valid field in the Ingress spec; the TLS Secret name is nested under each entry in the `.spec.tls` array.

Full explanation →

533

MCQmedium

A cluster administrator wants to prevent all pods in a namespace from running with privileged escalation. Which Pod Security Admission standard enforces this?

A.baseline

B.restricted

C.privileged

D.high

AnswerB

The restricted Pod Security Standard is the only built-in profile that explicitly mandates `allowPrivilegeEscalation: false` for all containers, effectively closing the door on any capability-based privilege escalation. It also requires a seccomp profile of RuntimeDefault, dropping all capabilities, and running as a non-root user, which collectively harden the container against breakout. By labeling the namespace with `pod-security.kubernetes.io/enforce=restricted`, the Pod Security Admission controller rejects any pod that violates these constraints, ensuring every pod in the namespace meets this strict baseline.

Why this answer

The 'restricted' Pod Security Admission (PSA) standard enforces the most stringent security controls, including preventing privileged escalation by setting `securityContext.AllowPrivilegeEscalation` to `false` and requiring containers to run as non-root. This directly addresses the cluster administrator's goal of blocking privilege escalation in all pods within a namespace.

Exam trap

CNCF often tests the distinction between 'baseline' and 'restricted' standards, where candidates mistakenly choose 'baseline' because it blocks some privilege escalation but fails to recognize that 'restricted' is the only standard that explicitly and comprehensively prohibits `AllowPrivilegeEscalation`.

How to eliminate wrong answers

Option A is wrong because the 'baseline' standard only prevents known privilege escalation attacks (e.g., via `CAP_SYS_ADMIN`) but does not explicitly require `AllowPrivilegeEscalation` to be `false`; it allows some flexibility for legacy workloads. Option C is wrong because the 'privileged' standard is the most permissive, allowing unrestricted access including privilege escalation, which is the opposite of what the question asks. Option D is wrong because 'high' is not a valid Pod Security Admission standard; the three defined standards are 'privileged', 'baseline', and 'restricted'.

Full explanation →

534

MCQmedium

What is the default restart policy for a pod created with 'kubectl run nginx --image=nginx'?

A.Always

B.OnFailure

C.Never

D.Restart

AnswerA

The default restart policy for a pod is Always. When you create a pod using `kubectl run` (or any command that doesn't explicitly set `restartPolicy`), the API server defaults the field to `Always`. This means the kubelet will automatically restart the pod's containers whenever they exit, regardless of the exit code, ensuring the pod remains running indefinitely. This is the expected behavior for long-running workloads like Deployments.

Why this answer

The default restart policy for a Pod created with `kubectl run` is `Always`. This is because `kubectl run` generates a deployment-like controller (or a standalone Pod in older versions) that defaults to the `Always` policy, meaning the kubelet will automatically restart the container regardless of its exit code. This ensures the Pod maintains a running state unless explicitly deleted or scaled down.

Exam trap

A common misconception is that `kubectl run` creates a bare Pod with no default restart policy, leading candidates to incorrectly assume `OnFailure` or `Never` is the default, when in fact `Always` is the implicit default for any Pod created without an explicit `--restart` flag.

How to eliminate wrong answers

Option B is wrong because `OnFailure` is not the default; it is a specific policy that restarts the container only when it exits with a non-zero exit code, and must be explicitly set via `--restart=OnFailure`. Option C is wrong because `Never` is not the default; it prevents any automatic restart and must be explicitly set via `--restart=Never`. Option D is wrong because `Restart` is not a valid restart policy in Kubernetes; the valid policies are `Always`, `OnFailure`, and `Never`.

Full explanation →

535

MCQmedium

You have a Service named 'my-svc' in the 'prod' namespace. What is the fully qualified DNS name for this Service?

A.my-svc.prod.svc.cluster.local

B.my-svc.svc.cluster.local

C.prod.my-svc.svc.cluster.local

D.my-svc.prod.cluster.local

AnswerA

This is the canonical fully qualified domain name (FQDN) for a Kubernetes Service. The format is `<service-name>.<namespace>.svc.<cluster-domain>`; here the service `my-svc` is in the `prod` namespace, and `svc` is the DNS subdomain reserved for Services. It resolves to the ClusterIP of the Service and is resolvable only from within the cluster (or via the cluster's DNS). No other components come before the service name.

Why this answer

The fully qualified DNS name for a Service in Kubernetes follows the pattern `<service-name>.<namespace>.svc.cluster.local`. For 'my-svc' in the 'prod' namespace, this resolves to 'my-svc.prod.svc.cluster.local'. This is the standard DNS naming convention used by CoreDNS (or kube-dns) for Service discovery within a cluster.

Exam trap

The CKAD exam often tests the exact order of components in the DNS name, specifically that the namespace comes before 'svc' and after the service name, and that 'svc' is a required subdomain, not optional.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component; the correct format requires the namespace ('prod') between the service name and 'svc'. Option C is wrong because it incorrectly places the namespace before the service name; the namespace must come after the service name, not before. Option D is wrong because it omits the 'svc' subdomain; the DNS name must include 'svc' to indicate it is a Service record, not a Pod or other resource.

Full explanation →

536

MCQmedium

A pod is unable to resolve the DNS name of a Service in the same namespace. The pod's /etc/resolv.conf shows 'nameserver 10.96.0.10'. What is the most likely cause?

A.The kube-dns Service is not running

B.The pod is using dnsPolicy: Default

C.The Service is of type ExternalName

D.The pod's /etc/hosts file is misconfigured

AnswerA

The kube-dns Service (typically implemented by CoreDNS) is the cluster-wide DNS server that responds to queries for Service or Pod names. If the Service object or its backing pods are absent or in a failed state, cluster DNS resolution completely fails, causing pods to be unable to resolve any Service name. This is the most direct and common cause of such a symptom.

Why this answer

The pod's /etc/resolv.conf shows nameserver 10.96.0.10, which is the default ClusterIP of the kube-dns Service. If the kube-dns Service is not running, the DNS resolver will fail to respond to queries, causing the pod to be unable to resolve the DNS name of any Service, including one in the same namespace. This is the most direct cause because the pod relies entirely on that nameserver for DNS resolution.

Exam trap

The trap here is that candidates often confuse dnsPolicy: Default with the default pod DNS policy (ClusterFirst), or assume that an ExternalName Service bypasses DNS entirely, when in fact all DNS queries go through the same kube-dns resolver.

How to eliminate wrong answers

Option B is wrong because dnsPolicy: Default means the pod inherits the node's DNS configuration, which would not point to 10.96.0.10; the given nameserver indicates the pod is using ClusterFirst (the default policy for pods), not Default. Option C is wrong because an ExternalName Service returns a CNAME record, not a ClusterIP, but DNS resolution would still work if kube-dns is running; the issue is the resolver not responding, not the Service type. Option D is wrong because the /etc/hosts file is used for local hostname resolution and does not affect DNS queries sent to the nameserver; misconfiguration there would not cause a failure to resolve a Service DNS name via the cluster DNS.

Full explanation →

537

MCQmedium

A pod is running but not responding to requests. The developer suspects the liveness probe is misconfigured. Which command can they use to check the probe configuration of a running pod?

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl exec <pod-name> -- env

D.kubectl get pod <pod-name>

AnswerB

kubectl describe pod displays the pod's full specification in a human-readable format, including each container's livenessProbe, readinessProbe, and startupProbe with their exact HTTP paths, ports, initialDelaySeconds, periodSeconds, failureThreshold, and timeoutSeconds. It also surfaces recent events, such as 'Liveness probe failed,' which directly indicate why the pod is unresponsive. This is the definitive command for inspecting probe configuration and diagnosing probe-related responsiveness issues.

Why this answer

`kubectl describe pod <pod-name>` displays the full pod specification, including the liveness probe configuration (e.g., `Liveness: http-get /healthz delay=0s timeout=1s period=10s #success=1 #failure=3`). This allows the developer to verify the probe type, endpoint, initial delay, timeout, and failure threshold directly from the running pod's definition.

Exam trap

The trap here is that candidates confuse `kubectl logs` (which shows runtime output) with `kubectl describe` (which shows configuration), assuming logs would reveal probe failures, but logs only show application output, not the probe definition itself.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` shows the container's stdout/stderr output, not the pod's configuration or probe settings; it cannot reveal how the probe is defined. Option C is wrong because `kubectl exec -- env` prints environment variables inside the container, which are unrelated to the liveness probe configuration stored in the pod spec. Option D is wrong because `kubectl get pod` only shows a summary (name, status, restarts, age) and does not include detailed probe parameters like path, port, or thresholds.

Full explanation →

538

Multi-Selectmedium

Which THREE of the following are valid Ingress pathTypes in Kubernetes networking.k8s.io/v1?

Select 3 answers

A.Prefix

B.Exact

C.Wildcard

D.Suffix

E.ImplementationSpecific

AnswersA, B, E

Prefix is a valid Ingress pathType that matches URL paths by whole path segments, not by raw string prefix. For example, a Prefix rule for /foo will match both /foo and /foo/bar, but it will not match /foobar because the match is evaluated on element boundaries separated by slashes. This makes Prefix the standard way to implement wildcard-style routing for a subtree of paths.

Why this answer

In Kubernetes networking.k8s.io/v1, the valid Ingress pathTypes are `Prefix`, `Exact`, and `ImplementationSpecific`. `Prefix` matches URL paths based on a prefix (e.g., `/api` matches `/api/v1`), `Exact` matches the path exactly (e.g., `/api` only matches `/api`), and `ImplementationSpecific` allows the ingress controller to define its own path matching logic. All three are defined in the v1 API.

Exam trap

Candidates often mistakenly believe that only `Prefix` and `Exact` are valid in networking.k8s.io/v1, but `ImplementationSpecific` is also a standard pathType in the stable v1 API.

Full explanation →

539

MCQmedium

A pod with a liveness probe using 'httpGet' is restarting repeatedly. The probe checks '/healthz' on port 8080. The application is healthy and responds with HTTP 200. What is the most likely cause?

A.The initialDelaySeconds is too high

B.The timeoutSeconds value is too low

C.The liveness probe is checking the wrong port

D.The readiness probe is misconfigured

AnswerB

When timeoutSeconds is set too low, the kubelet gives the HTTP GET request insufficient time to receive a response. If the application's health endpoint occasionally takes longer than the timeout, the probe is marked failed, and after exceeding failureThreshold the container is restarted. This matches the observed behavior of a container that restarts repeatedly even though the app itself is functional, making this the correct explanation.

Why this answer

The liveness probe is restarting the pod despite the application returning HTTP 200 on /healthz. A timeoutSeconds value that is too low can cause the probe to fail if the application takes longer than the timeout to respond, even though it is healthy. Kubernetes will restart the container when the probe fails, leading to repeated restarts.

Exam trap

The trap here is that candidates assume a healthy application always responds instantly, but Kubernetes probes have strict timeouts; a low timeoutSeconds can cause restarts even when the app is functioning correctly.

How to eliminate wrong answers

Option A is wrong because a high initialDelaySeconds delays the start of probing but does not cause repeated restarts once the probe begins; it would only prevent early failures. Option C is wrong because the probe is explicitly checking port 8080 and the application is healthy on that port, so the port is correct. Option D is wrong because a readiness probe misconfiguration affects traffic routing, not container restarts; liveness probes control restarts, and readiness probes do not trigger restarts.

Full explanation →

540

MCQmedium

You create a ResourceQuota in a namespace that sets requests.cpu: '1' and limits.cpu: '2'. A pod spec has no resource limits or requests. What happens when you try to create this pod?

A.The pod is created without limits, but the quota is enforced at runtime

B.The pod creation is denied because the spec does not specify resource limits or requests

C.The pod is created and the quota is ignored

D.The pod is created with default limits from the LimitRange

AnswerB

When a ResourceQuota is active in a namespace, it imposes an admission-time validation that every pod in that namespace must specify resource requests (and limits if the quota includes limits). Because the pod spec in this scenario omits both resource limits and requests, the admission controller denies creation—there is nothing to count against the quota, so the request fails.

Why this answer

When a ResourceQuota is defined with requests.cpu and limits.cpu, Kubernetes requires that every pod in that namespace have explicit resource requests and limits that match the quota constraints. If a pod spec omits these fields, the API server denies the pod creation because it cannot determine whether the pod complies with the quota. This is enforced at admission time, not at runtime.

Exam trap

The trap here is that candidates assume a LimitRange will automatically apply default resource values, but without a LimitRange, the pod creation is denied outright due to the missing fields required by the ResourceQuota.

How to eliminate wrong answers

Option A is wrong because the quota is enforced at admission time, not at runtime; the pod is never created if it lacks required resource specifications. Option C is wrong because the quota is never ignored; it is a hard constraint that the API server enforces during admission. Option D is wrong because a LimitRange can provide default values, but the question does not mention a LimitRange existing in the namespace; without one, the pod creation is denied due to missing resource fields.

Full explanation →

541

Multi-Selectmedium

You are using Helm to manage a chart. Which commands are valid to list installed releases? (Choose TWO)

Select 2 answers

A.helm ls

B.helm upgrade

C.helm status

D.helm history

E.helm list

AnswersA, E

helm ls is correct because it is a built-in alias for the `helm list` command, which enumerates all deployed Helm releases in your current Kubernetes namespace. When run, it queries Helm's release storage (typically Secrets or ConfigMaps) and displays a table with release name, status, revision, and chart details. The shorthand form is widely used in scripts and everyday operations, making it a convenient equivalent to the command that the question asks about.

Why this answer

`helm ls` and `helm list` are both valid commands to list installed releases in Helm. `helm ls` is an alias for `helm list`, and both display all deployed releases in the current namespace by default. These commands are essential for managing Helm-based deployments.

Exam trap

The CKAD exam often tests the alias relationship between `helm ls` and `helm list`, and candidates may mistakenly think only one is valid or confuse `helm list` with `helm history` which shows revision history for a single release.

Full explanation →

542

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete and recreate the pod to clear the crash loop

B.Delete the namespace and redeploy all workloads

C.Increase the memory limit in the pod's container resource specification

D.Increase the CPU request for the container

AnswerC

OOMKilled is the kubelet's signal that the container's memory usage exceeded its specified limit, prompting the kernel OOM killer to terminate the process. Raising the memory limit in the container's resource specification permits the container to consume more memory before that threshold is reached, directly addressing the root cause and allowing the pod to remain running. This is the expected fix when the application's nominal memory footprint is larger than the old limit but still fits within node capacity.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to allocate more memory without being terminated by the Out-of-Memory (OOM) killer.

Exam trap

The trap here is that candidates often confuse OOMKilled with a general crash and choose to delete and recreate the pod (Option A), not realizing that the resource limit itself must be adjusted to prevent recurrence.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the new pod will still have the same resource constraints and will be OOMKilled again. Option B is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that does not address the specific memory limit problem and would cause unnecessary downtime. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOMKilled status is caused by exceeding the memory limit, not CPU constraints.

Full explanation →

543

MCQmedium

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

C.CronJob

D.DaemonSet

AnswerB

StatefulSet is the correct controller because it assigns each pod a stable, ordinal hostname (e.g., db-0, db-1) backed by a Headless Service, so cluster members can discover each other deterministically. Its volumeClaimTemplates provision a unique PersistentVolumeClaim for every replica, ensuring data survives restarts. StatefulSet also supports ordered, graceful deployment and scaling, which matches the initialization and quorum requirements of stateful databases.

Why this answer

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.

Exam trap

CNCF often tests the misconception that Deployment can handle stateful workloads by using PersistentVolumeClaims, but they fail to recognize that Deployment lacks stable network identities and ordered pod management, which are critical for database clustering.

How to eliminate wrong answers

Option A is wrong because Deployment does not guarantee stable network identities or ordered pod creation; pods are treated as ephemeral and interchangeable, which is unsuitable for stateful applications requiring persistent storage per pod. Option C is wrong because CronJob is designed for scheduled, batch jobs (running to completion) and does not manage long-running stateful pods with persistent storage or stable identities. Option D is wrong because DaemonSet ensures one pod per node, not ordered creation or per-pod persistent storage; it is intended for node-level services like logging or monitoring, not stateful databases.

Full explanation →

544

MCQmedium

A pod in the 'staging' namespace is in a CrashLoopBackOff state. You run 'kubectl logs pod -n staging' and see: 'Error: container has been OOMKilled'. The pod YAML has resources: requests: memory: 256Mi, limits: memory: 256Mi. Which change should you make first?

A.Increase the memory limit to 512Mi.

B.Increase the CPU limit to 1.

C.Reduce the memory request to 128Mi.

D.Set memory request to 512Mi and memory limit to 256Mi.

AnswerA

Raising the memory limit from 256Mi to 512Mi directly addresses the container's memory usage ceiling. OOMKilled occurs when the container's memory footprint exceeds its cgroup memory limit, causing the kernel's OOM killer to terminate the process. Since the container is already crashing at the current 256Mi limit, increasing it to 512Mi provides the necessary headroom for the workload to operate without being killed.

Why this answer

The pod is in CrashLoopBackOff due to OOMKill, meaning the container exceeded its memory limit and was terminated. Since the current memory limit is 256Mi and the container needs more, increasing the limit to 512Mi directly addresses the out-of-memory condition. This is the correct first step because it provides the container with the additional memory it requires to run without being killed.

Exam trap

CNCF often tests the distinction between requests and limits, and the trap here is that candidates might confuse reducing the request (option C) as a solution, when in fact the OOMKill is caused by hitting the limit, not the request.

How to eliminate wrong answers

Option B is wrong because the issue is memory exhaustion (OOMKill), not CPU; increasing the CPU limit does not resolve the out-of-memory condition. Option C is wrong because reducing the memory request to 128Mi would lower the guaranteed memory, potentially worsening the OOM situation and increasing the risk of the container being killed. Option D is wrong because setting the memory request higher than the limit (512Mi request vs 256Mi limit) is invalid in Kubernetes; the request must be less than or equal to the limit, and this configuration would be rejected by the API server.

Full explanation →

545

Multi-Selecthard

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

Select 2 answers

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

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

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

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

E.Init containers run to completion one at a time before any app container starts, so the main container will not begin until the init container exits successfully.

AnswersC, E

emptyDir is a Pod-scoped volume that exists for the Pod's lifetime and can be mounted into multiple containers. Mounting it in both the init container and the main container lets the init container write configuration files that the main container later reads, satisfying the shared-volume requirement.

Why this answer

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.

Exam trap

The trap here is assuming init containers can run in parallel with app containers or that readiness probes apply to them, when they must complete before any app container starts.

Full explanation →

546

MCQeasy

Which Service type is used to expose a Service on a static port on each node in the cluster?

A.ClusterIP

B.ExternalName

C.NodePort

D.LoadBalancer

AnswerC

NodePort exposes the Service on a static port in the default range 30000–32767 on every node in the cluster. kube-proxy listens on this NodePort and forwards traffic to the corresponding ClusterIP, which then load-balances to the backing pods. This allows external clients to reach the Service by connecting to any node's IP address with the NodePort, making it the correct Service type for static port exposure.

Why this answer

NodePort is the correct Service type because it exposes the Service on a static port (in the range 30000-32767) on every node's IP address in the cluster. Traffic sent to any node's IP on that port is forwarded to the Service's ClusterIP and then to the selected Pods, enabling external access without a cloud load balancer.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking LoadBalancer also exposes a static port on each node, but LoadBalancer actually creates an external LB that routes to NodePort or ClusterIP, not a static port on every node itself.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an ingress or proxy. Option B is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any port or proxy traffic; it is used for internal DNS aliasing, not for exposing services on node ports. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, but it does not expose the Service on a static port on each node; it relies on the underlying NodePort or ClusterIP for routing.

Full explanation →

547

MCQmedium

You want to expose a Deployment 'app' externally on port 30080 on each node. What service type should you use?

A.LoadBalancer

B.ExternalName

C.NodePort

D.ClusterIP

AnswerC

NodePort is the correct choice because it exposes the service on a static port on every worker node's IP address, allowing external clients to access the deployment via any node's IP:nodePort. This provides direct external access to the pods without needing a cloud load balancer, and it's the standard way to expose a deployment on a specific port for simple use cases.

Why this answer

A NodePort service exposes the Deployment on a static port (30080) on each node's IP address, making it accessible externally via <NodeIP>:30080. This is the correct choice because the requirement explicitly asks to expose the app on port 30080 on each node, which matches the NodePort service type's behavior of opening a specific port on every node in the cluster.

Exam trap

The trap here is that candidates may confuse NodePort with LoadBalancer, thinking that exposing on 'each node' implies a load balancer, but NodePort specifically provides per-node port exposure without requiring a cloud provider.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer service provisions an external load balancer (typically from a cloud provider) and does not guarantee exposure on a specific port on each node; it creates a single external IP and port, not per-node ports. Option B is wrong because an ExternalName service maps a service to a DNS name (via CNAME) and does not expose any ports or provide external access to a Deployment; it is used for internal DNS aliasing. Option D is wrong because a ClusterIP service is only reachable within the cluster via its internal IP and cannot be accessed externally from outside the cluster.

Full explanation →

548

MCQeasy

A developer needs to deploy a container that runs a batch job to process data once and then exit. The job should be restarted only if it fails. Which Kubernetes resource should be used?

A.DaemonSet

B.Deployment

C.Job

D.StatefulSet

AnswerC

A Job creates one or more pods and tracks them until a specified number of successful completions are reached, which exactly matches the semantics of a batch operation. The Job controller uses a restart policy of Never or OnFailure, and it implements backoff limits, active deadlines, parallelism, and completion counts to govern how failed pods are retried. This allows the developer to express 'run this container once' and have Kubernetes guarantee the task eventually ends in a completed state, or fail according to policy. Hence, for a container that runs a batch job and exits, Job is the correct workload controller.

Why this answer

A Kubernetes Job is the correct resource for a batch workload that runs to completion and exits. It ensures the pod is restarted only on failure (via the `RestartPolicy: OnFailure` or `Never`), which matches the requirement of restarting only if the job fails. Deployments and DaemonSets are designed for long-running processes, not termination.

Exam trap

The trap here is that candidates often confuse a Job with a Deployment because both can run containers, but a Deployment is designed for long-running services and will restart pods even on successful completion, which violates the 'run once' requirement.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures one pod runs on every node and is intended for continuous daemon processes (e.g., log collectors), not for batch jobs that exit. Option B is wrong because a Deployment manages a set of pods that should run indefinitely, maintaining a desired replica count; it will restart pods regardless of exit reason, which does not match the 'restart only on failure' requirement. Option D is wrong because a StatefulSet is for stateful applications requiring stable network identities and persistent storage, not for ephemeral batch processing.

Full explanation →

549

MCQhard

A Deployment has replicas: 3 and uses a ConfigMap. The ConfigMap is updated. The developer wants to update the pods to use the new ConfigMap without recreating the Deployment. What is the correct approach?

A.kubectl rollout restart deployment/<name>

B.kubectl set image deployment/<name> <container>=<new-image>

C.The pods automatically mount the new ConfigMap within seconds

D.Delete and recreate each pod manually

AnswerA

kubectl rollout restart deployment/<name> is correct because it modifies the pod template's annotation (spec.template.metadata.annotations) without changing container images, forcing the Deployment controller to create a new ReplicaSet and perform a rolling update. New pods are scheduled with the patched template and therefore mount the latest ConfigMap data at container start, while old pods are terminated gradually. This is the recommended declarative way to reload configuration changes with zero downtime and full rollout history.

Why this answer

A `kubectl rollout restart deployment/<name>` triggers a rolling restart of the Pods managed by the Deployment. Since ConfigMaps are mounted as volumes or injected as environment variables at Pod creation time, the only way to pick up updated ConfigMap data without recreating the Deployment object itself is to force the existing Pods to be terminated and recreated. The Deployment controller handles this gracefully, ensuring zero downtime by following the configured rolling update strategy.

Exam trap

The trap here is that candidates assume ConfigMaps are dynamically updated in running Pods (Option C), but in reality, Pods must be recreated to consume updated ConfigMap data unless the application explicitly watches for file changes.

How to eliminate wrong answers

Option B is wrong because `kubectl set image` updates the container image, not the ConfigMap; it does not cause Pods to reload ConfigMap data. Option C is wrong because ConfigMaps are not automatically updated inside running Pods — they are snapshotted at Pod start; even if the volume is mounted as a subPath or as environment variables, the Pod must be restarted to reflect changes. Option D is wrong because manually deleting and recreating Pods is error-prone, does not leverage the Deployment’s rollout history or update strategy, and violates the principle of declarative management; the correct imperative command is `kubectl rollout restart`.

Full explanation →

550

MCQmedium

Which command creates a TLS secret named 'tls-secret' using certificate file 'tls.crt' and key file 'tls.key'?

A.kubectl create secret docker-registry tls-secret --docker-server=...

B.kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key

C.kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key

D.kubectl create secret generic tls-secret --from-literal=tls.crt=...

AnswerB

This is the correct command because `kubectl create secret tls` creates a secret with the type `kubernetes.io/tls`. The `--cert` and `--key` flags read the PEM-encoded `tls.crt` and `tls.key` files respectively, and the resulting secret stores them under the exact data keys `tls.crt` and `tls.key` that Kubernetes components like the Ingress controller and kubelet expect when loading TLS certificates. This type also validates that the provided key and certificate are present and correctly named at creation time, ensuring the secret is immediately usable.

Why this answer

The `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and key pair. The `--cert` and `--key` flags directly reference the PEM-encoded certificate file (`tls.crt`) and private key file (`tls.key`), which Kubernetes stores as `tls.crt` and `tls.key` data entries in the Secret object.

Exam trap

The trap here is that candidates often choose Option C because they think `--from-file` can create a TLS secret, but they overlook that the secret type must be `kubernetes.io/tls` and the data keys must be exactly `tls.crt` and `tls.key` — a generic secret with arbitrary keys will not work for TLS termination.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret docker-registry` creates a Docker registry authentication secret, not a TLS secret; it uses `--docker-server`, `--docker-username`, etc. Option C is wrong because `kubectl create secret generic` with `--from-file` stores the entire file contents under arbitrary keys (e.g., the filename), not under the standard `tls.crt` and `tls.key` keys required for TLS secrets; the resulting secret would not be recognized as a TLS secret by ingress controllers or other components. Option D is wrong because `--from-literal` expects a literal key=value pair, not a file path; it would store the string 'tls.crt=...' as a literal, not the certificate content.

Full explanation →

551

MCQeasy

Which 'kubectl' command creates a pod named 'test-pod' using the nginx image and outputs the YAML manifest without actually creating it?

A.kubectl apply -f pod.yaml

B.kubectl run test-pod --image=nginx --dry-run=client -o yaml

C.kubectl run test-pod --image=nginx --dry-run=server

D.kubectl run test-pod --image=nginx --dry-run=client -o json

AnswerB

This is the canonical imperative command for manifest generation: `kubectl run` creates a Pod object from flags, `--dry-run=client` tells kubectl to only print the object locally without sending anything to the API server, and `-o yaml` formats that object as YAML on stdout. It gives you a complete Pod spec (with default values and a generated name) that you can review, edit, or pipe to `kubectl apply -f -`. This is precisely what the question asks for — a command that generates a Pod manifest without creating the Pod.

Why this answer

`kubectl run test-pod --image=nginx --dry-run=client -o yaml` generates the YAML manifest for a pod named 'test-pod' using the nginx image without actually creating it. The `--dry-run=client` flag simulates the request locally and prevents API server submission, while `-o yaml` formats the output as YAML.

Exam trap

The CKAD exam often tests the distinction between `--dry-run=client` and `--dry-run=server`, and the requirement for output format (`-o yaml` vs `-o json`), tricking candidates into choosing an option that either does not output the manifest or outputs it in the wrong format.

How to eliminate wrong answers

Option A is wrong because `kubectl apply -f pod.yaml` creates resources from a file and does not output a manifest without creation; it actually applies the manifest to the cluster. Option C is wrong because `--dry-run=server` sends the request to the API server for validation but still does not create the resource, but the question specifically requires outputting the YAML manifest, which `-o yaml` is missing in this option. Option D is wrong because `-o json` outputs the manifest in JSON format, not YAML, which does not meet the requirement for YAML output.

Full explanation →

552

MCQeasy

You create a ConfigMap named 'app-config' with the command 'kubectl create configmap app-config --from-literal=key1=value1'. Which of the following correctly mounts this ConfigMap as environment variables in a pod?

A.env: - name: key1 valueFrom: configMapKeyRef: name: app-config key: key1

B.volumes: - name: config-volume configMap: name: app-config volumeMounts: - name: config-volume mountPath: /etc/config

C.env: - name: key1 valueFrom: configMapRef: name: app-config

D.envFrom: - configMapRef: name: app-config

AnswerD

This is the correct approach: the envFrom field accepts a list of configMapRefs, and when a ConfigMap is referenced this way, all of its key-value pairs are automatically exposed as environment variables in the container. The key becomes the environment variable name and the value becomes its value, so no per-key declarations are needed. This exactly fulfills the requirement to mount the entire ConfigMap as environment variables, and it is the canonical pattern in Kubernetes for such bulk injection.

Why this answer

`envFrom` with `configMapRef` is the Kubernetes mechanism to expose all key-value pairs from a ConfigMap as environment variables in a pod. This directly mounts the ConfigMap created with `--from-literal=key1=value1` so that `key1` becomes an environment variable with value `value1`.

Exam trap

The trap here is that candidates confuse `envFrom` with `env` and `configMapRef` with `configMapKeyRef`, or they incorrectly think volume mounts are equivalent to environment variable injection.

How to eliminate wrong answers

Option A is wrong because while the syntax is valid for a single key reference, it requires explicitly listing each key, which is not the 'correctly mounts this ConfigMap' approach when the question implies using the entire ConfigMap; it is a valid but incomplete method for the scenario. Option B is wrong because it describes mounting the ConfigMap as files in a volume at `/etc/config`, not as environment variables. Option C is wrong because `configMapRef` is not a valid field under `env`; the correct field is `configMapKeyRef`.

Full explanation →

553

MCQhard

You are tasked with running a batch job that processes 100 items in parallel, using a Kubernetes Job. The Job should ensure that all items are processed even if some pods fail, and the total number of pod failures should be limited to 3. Which Job configuration is correct?

A.Set spec.parallelism: 100, spec.completions: 100, spec.backoffLimit: 3

B.Set spec.parallelism: 1, spec.completions: 100, spec.backoffLimit: 3

C.Set spec.parallelism: 100, spec.completions: 1, spec.backoffLimit: 3

D.Set spec.parallelism: 100, spec.completions: 100, spec.activeDeadlineSeconds: 300

AnswerA

This configuration correctly matches the workload: spec.parallelism: 100 lets up to 100 pods run simultaneously to process the 100 items in parallel, while spec.completions: 100 ensures the Job is not marked successful until each of the 100 items is handled by a successful pod completion. Adding spec.backoffLimit: 3 caps the number of retries for failing pods to 3, providing a sane bound on wasted work. Together these fields encode the exact concurrency and completion requirements for a 100-item batch without any time-based preemption.

Why this answer

Setting `spec.parallelism: 100` allows 100 pods to run concurrently, `spec.completions: 100` ensures all 100 items are processed (each pod handles one item), and `spec.backoffLimit: 3` limits the total number of pod failures to 3 before the Job is marked as failed. This configuration guarantees that even if some pods fail, the Job will retry them up to the specified backoff limit, ensuring all items are processed.

Exam trap

The trap here is confusing `backoffLimit` (which limits pod failures) with `activeDeadlineSeconds` (which limits the overall Job runtime), leading candidates to pick Option D, which fails to cap failures and instead imposes a time constraint.

How to eliminate wrong answers

Option B is wrong because `spec.parallelism: 1` forces pods to run sequentially, not in parallel, which defeats the requirement to process 100 items in parallel. Option C is wrong because `spec.completions: 1` means the Job only needs one successful pod completion, so it will not process all 100 items. Option D is wrong because `spec.activeDeadlineSeconds: 300` sets a time limit for the Job, but does not limit the number of pod failures; the `backoffLimit` field is required to cap failures at 3.

Full explanation →

554

Multi-Selectmedium

Which TWO of the following are valid uses of init containers? (Select 2)

Select 2 answers

A.Running a log collection agent continuously

B.Performing health checks on the main container

C.Setting ownership and permissions on a shared volume before the main container uses it

D.Serving HTTP traffic to the main container

E.Waiting for an external database to be ready before starting the main application

AnswersC, E

Before the main application container starts, an init container can mount a shared volume and apply file ownership, permissions, or SELinux labels using familiar Unix tools like chown and chmod. Because init containers execute sequentially to completion, any changes it makes on the volume persist for main containers, a pattern that is especially useful with persistent volumes or emptyDir mounts.

Why this answer

Init containers run to completion before any pod containers start, making them ideal for filesystem setup tasks like changing ownership (chown) or permissions (chmod) on a shared volume. This ensures the main container can access the volume without requiring privileged mode or extra security context settings.

Exam trap

Kubernetes often tests the misconception that init containers can run continuously or serve as sidecars, but the key trap is that init containers must terminate successfully before the main containers start, so only one-time setup tasks are valid.

Full explanation →

555

MCQmedium

What is the purpose of the `IngressClass` resource in Kubernetes?

A.To enable path-based routing.

B.To define the TLS certificate for an Ingress.

C.To specify which Ingress controller should implement the Ingress.

D.To set the default backend for an Ingress.

AnswerC

The IngressClass resource exists to name a specific ingress controller, such as nginx or traefik, in its spec.controller field, and it can also set parameters for that controller. An Ingress declares a class via spec.ingressClassName, and the referenced controller then picks up and implements the Ingress's routing rules. This decouples the Ingress manifest from vendor-specific controller details, allowing the cluster administrator to choose the implementation without editing each Ingress.

Why this answer

The `IngressClass` resource decouples the Ingress definition from the specific Ingress controller implementation. It allows you to specify which controller (e.g., NGINX, HAProxy, Traefik) should process the Ingress by referencing the `spec.controller` field, enabling multi-controller clusters and dynamic routing decisions.

Exam trap

The trap here is that candidates confuse the IngressClass with Ingress features like path routing or TLS, but the CKAD exam specifically tests that IngressClass is the mechanism to select which controller implementation handles the Ingress.

How to eliminate wrong answers

Option A is wrong because path-based routing is a feature of the Ingress resource itself (via `spec.rules.http.paths`), not the IngressClass. Option B is wrong because TLS certificates are defined in the Ingress resource's `spec.tls` field, not in the IngressClass. Option D is wrong because the default backend is set within the Ingress resource's `spec.defaultBackend`, not by the IngressClass.

Full explanation →

556

MCQmedium

A headless service is created with 'clusterIP: None'. What is the primary use case for such a service?

A.To allow direct pod-to-pod DNS resolution for StatefulSets.

B.To provide a stable IP address for the service.

C.To expose the service externally without a load balancer.

D.To enable DNS round-robin across all pods.

AnswerA

Headless services (clusterIP: None) are used with StatefulSets to provide stable network identities. Instead of a virtual IP, the service creates DNS A records for each pod's unique name (e.g., pod-0.service.namespace.svc.cluster.local) that resolve directly to pod IPs. This allows clients to reach a specific pod directly by name, which is essential for stateful applications where each replica maintains its own state and peers need to discover each other by stable identity.

Why this answer

A headless service (clusterIP: None) is primarily used with StatefulSets to enable direct pod-to-pod DNS resolution. Instead of a single virtual IP, the DNS returns the individual pod IPs (A/AAAA records) or SRV records, allowing each pod to be addressed by its stable network identity (e.g., pod-name.service-name.namespace.svc.cluster.local). This is essential for stateful applications like databases that require stable peer discovery.

Exam trap

The trap here is that candidates confuse headless services with regular ClusterIP services, assuming the primary benefit is DNS round-robin (Option D), when in fact the key differentiator is the absence of a single virtual IP to enable direct pod identity resolution for StatefulSets.

How to eliminate wrong answers

Option B is wrong because a headless service does not provide a stable IP address; it deliberately omits a cluster IP to return pod IPs directly. Option C is wrong because headless services are not used for external exposure; external access typically requires a NodePort, LoadBalancer, or Ingress. Option D is wrong because DNS round-robin is the default behavior for regular ClusterIP services (via kube-dns/CoreDNS), not a primary use case for headless services; headless services return all pod IPs, leaving load balancing to the client.

Full explanation →

557

MCQeasy

You have a Deployment named 'web-app' with 5 replicas. You run the command: kubectl set image deployment/web-app web-app=nginx:1.25. Which command can you use to monitor the progress of the rollout?

A.kubectl describe deployment/web-app

B.kubectl rollout history deployment/web-app

C.kubectl rollout status deployment/web-app

D.kubectl get events --watch

AnswerC

kubectl rollout status deployment/web-app attaches to the Deployment's status and blocks until the rollout reaches completion, printing progress messages like 'Waiting for deployment spec update...' and finally 'deployment "web-app" successfully rolled out'. It returns a non-zero exit code if the rollout times out or fails, making it the canonical command for checking rollout success. It also supports a `--timeout` flag to bound the wait, which is essential in scripts and CI pipelines.

Why this answer

`kubectl rollout status deployment/web-app` is the dedicated command to monitor the progress of a rollout, providing real-time updates on whether the rollout is succeeding, pending, or failed. It watches the deployment's status conditions and reports when the new ReplicaSet has fully replaced the old one, making it the precise tool for tracking the progress of the `kubectl set image` change.

Exam trap

The trap here is that candidates confuse `kubectl rollout status` with `kubectl rollout history` or `kubectl describe`, mistakenly thinking a static view or revision list can show live progress, when only `rollout status` provides real-time monitoring of the rollout's completion.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment/web-app` shows the current state and configuration of the deployment, including the rollout strategy and conditions, but it does not actively monitor or stream progress; it only provides a static snapshot. Option B is wrong because `kubectl rollout history deployment/web-app` displays the revision history of the deployment (e.g., revision numbers and change causes), but it does not show the current rollout status or progress. Option D is wrong because `kubectl get events --watch` streams all cluster events, which is too broad and noisy; while it may include rollout-related events, it is not a focused or efficient way to monitor the specific rollout progress of the deployment.

Full explanation →

558

MCQmedium

A Deployment is configured with 'resources.requests.memory: 256Mi' and 'resources.limits.memory: 512Mi'. The node runs out of memory. Which pods will be the first to be evicted?

A.The node will not evict pods if limits are set

B.This pod will be evicted first because it has a memory limit

C.BestEffort pods first, then this Burstable pod, then Guaranteed pods last

D.All pods are evicted simultaneously

AnswerC

Under node memory pressure, the kubelet selects eviction victims by QoS class: it first targets BestEffort pods (no requests/limits), then Burstable pods (requests set, limits may differ), and finally Guaranteed pods (requests equal limits). Because this deployment sets only a memory request, it is Burstable, so it will be evicted after every BestEffort pod on the node has been reclaimed and before any Guaranteed pod is touched. This ordering is a core part of the Kubernetes eviction mechanism and helps protect the most critical workloads during resource shortages.

Why this answer

C is correct because Kubernetes evicts pods based on their Quality of Service (QoS) class when a node runs out of memory. BestEffort pods (no requests/limits) are evicted first, followed by Burstable pods (requests < limits, as in this case), and Guaranteed pods (requests == limits) are evicted last. This ensures that pods with stricter resource guarantees are more protected during memory pressure.

Exam trap

CNCF often tests the misconception that setting a memory limit alone protects a pod from eviction, but the key factor is the QoS class derived from the relationship between requests and limits, not just the presence of limits.

How to eliminate wrong answers

Option A is wrong because the node will evict pods when memory is exhausted, regardless of whether limits are set; the kubelet uses the QoS class to determine eviction order. Option B is wrong because this Burstable pod will not be evicted first; BestEffort pods (with no resource specifications) are evicted before any Burstable pod. Option D is wrong because eviction is not simultaneous; pods are evicted in a specific order based on their QoS class, starting with BestEffort, then Burstable, and finally Guaranteed.

Full explanation →

559

MCQmedium

A CronJob is configured with 'concurrencyPolicy: Forbid'. What happens if the scheduled time arrives while the previous job is still running?

A.The new job is skipped until the next scheduled time

B.The new job starts immediately, running concurrently

C.The running job is terminated and the new job starts

D.The CronJob enters an error state

AnswerA

With concurrencyPolicy set to Forbid, the CronJob controller checks whether any Job created from this CronJob is currently active. If a previous Job is still running at the scheduled time, the controller simply skips the newly triggered execution. The missed run is not queued or retried; it is permanently lost until the next schedule fires.

Why this answer

When `concurrencyPolicy: Forbid` is set on a CronJob, Kubernetes ensures that no new Job is created if the previous Job is still running. The CronJob controller checks the status of the most recent Job; if it has not completed, the scheduled execution is skipped entirely, and the next run occurs at the next scheduled time. This prevents overlapping executions, which is critical for workloads that must not run concurrently.

Exam trap

The trap here is that candidates often confuse `concurrencyPolicy: Forbid` with `concurrencyPolicy: Replace`, which would terminate the running job; or they assume that a skipped job will be retried immediately, but Kubernetes does not automatically retry skipped executions under the `Forbid` policy.

How to eliminate wrong answers

Option B is wrong because `concurrencyPolicy: Forbid` explicitly prevents concurrent runs; the new job does not start immediately. Option C is wrong because `concurrencyPolicy: Forbid` does not terminate the running job; it only skips the new execution. Option D is wrong because the CronJob does not enter an error state; it simply logs a skip event and continues to monitor future schedules.

Full explanation →

560

MCQeasy

Which Service type exposes a Service externally via each Node's IP on a static port?

A.NodePort

B.ClusterIP

C.LoadBalancer

D.ExternalName

AnswerA

NodePort exposes a service by allocating a static port (in the default 30000-32767 range) on every node in the cluster. Clients reach the service by connecting to any node's IP address at that port, and kube-proxy forwards the traffic to the service's ClusterIP, which then load-balances to endpoint pods. Since the port is open on all nodes, this type directly satisfies the requirement for node-level external exposure.

Why this answer

A NodePort Service exposes the Service on each Node's IP address at a static port (in the range 30000-32767 by default). This allows external traffic to reach the Service by sending requests to any Node's IP and the specified NodePort, which then forwards traffic to the corresponding ClusterIP Service and ultimately to the Pods.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer also uses static Node ports, but LoadBalancer relies on an external cloud LB and does not guarantee a static port on each Node's IP.

How to eliminate wrong answers

Option B (ClusterIP) is wrong because it exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an Ingress or a proxy. Option C (LoadBalancer) is wrong because it relies on an external cloud provider's load balancer to expose the Service, not directly on each Node's IP with a static port. Option D (ExternalName) is wrong because it maps a Service to a DNS name (via CNAME records) and does not expose any port or IP; it is used for internal cluster DNS aliasing, not external access.

Full explanation →

561

Multi-Selectmedium

Which TWO commands can be used to update the image of a Deployment? (Select two)

Select 2 answers

A.kubectl set image deployment/myapp app=nginx:1.21

B.kubectl edit deployment myapp

C.kubectl update deployment myapp --image=nginx:1.21

D.kubectl patch deployment myapp -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"nginx:1.21"}]}}}}'

E.kubectl replace deployment myapp --image=nginx:1.21

AnswersA, D

This command is correct because it imperatively modifies the container's image using the syntax `deployment/<name> <container>`=`<new-image>`. It directly patches the live Deployment object and triggers a rollout if the pod template changes. It is the most concise and readable way to update an image for a single Deployment, which is why it is commonly used in CI/CD pipelines.

Why this answer

Options A and D are correct because `kubectl set image` directly updates the container image, and `kubectl patch` modifies the Deployment manifest using a JSON patch. Option B is incorrect because `kubectl edit` only opens the manifest in an editor, requiring manual changes; it does not directly update the image. Option C is incorrect because `kubectl update` is not a valid command.

Option E is incorrect because `kubectl replace` requires a full manifest file, not just an image flag.

Exam trap

The CKAD exam often tests the distinction between valid imperative commands (`set image`, `edit`, `patch`) and invalid or misused commands (`update`, `replace` with wrong flags), so candidates must remember that `kubectl update` does not exist and `kubectl replace` requires a full manifest, not a flag-based update.

Full explanation →

562

MCQhard

You have a Deployment that is currently paused. You want to resume the rollout and then check the status of the rollout. Which set of commands should you run?

A.kubectl rollout pause deployment/myapp && kubectl rollout status deployment/myapp

B.kubectl rollout resume deployment/myapp && kubectl rollout history deployment/myapp

C.kubectl rollout undo deployment/myapp && kubectl rollout status deployment/myapp

D.kubectl rollout resume deployment/myapp && kubectl rollout status deployment/myapp

AnswerD

The correct sequence is `kubectl rollout resume` to unpause the deployment, letting the deployment controller continue the rolling update from where it left off, followed by `kubectl rollout status` to poll the rollout until it completes or reports an error. The status command blocks until the rollout condition is successful, giving immediate and accurate feedback on the health of the deployment. This directly addresses the user's intent: resume the paused deployment and confirm it reaches the desired state.

Why this answer

First, resume the rollout with 'kubectl rollout resume deployment/<name>', then check status with 'kubectl rollout status deployment/<name>'. Option D is correct. Option B uses 'kubectl rollout history' which shows revision history, not current status.

Full explanation →

563

MCQhard

Which of the following is a valid YAML snippet for a container that sets the seccomp profile to 'RuntimeDefault' in a PodSecurityContext?

A.securityContext: seccompProfile: type: RuntimeDefault

B.securityContext: seccompProfile: profile: RuntimeDefault

C.securityContext: seccomp: RuntimeDefault

D.securityContext: seccomp: type: RuntimeDefault

AnswerA

Correct. In the Pod/container securityContext, seccompProfile is a structured object that selects the seccomp profile applied to the container. Its only required and valid field for this purpose is 'type', and setting type: RuntimeDefault instructs the container runtime (e.g., containerd/Docker) to use the runtime's default seccomp profile, which blocks a defined set of dangerous syscalls while allowing normal operation. This is the correct syntax and is fully supported in Kubernetes v1.19+ when the seccompProfile field is used in the API.

Why this answer

In a PodSecurityContext, the seccomp profile is configured under the `seccompProfile` field with a `type` key set to `RuntimeDefault`. This tells the container runtime (e.g., containerd) to use the default seccomp profile provided by the runtime, which blocks a set of syscalls that are not typically needed by containers.

Exam trap

The trap here is that candidates confuse the `type` key (which specifies the profile type, e.g., RuntimeDefault, Localhost, Unconfined) with a `profile` key, or they flatten the YAML structure by omitting the `seccompProfile` nesting, leading to invalid configuration.

How to eliminate wrong answers

Option B is wrong because it uses `profile: RuntimeDefault` instead of `type: RuntimeDefault`; the correct key under `seccompProfile` is `type`, not `profile`. Option C is wrong because it uses `seccomp: RuntimeDefault` as a flat key-value pair, but the seccomp configuration must be nested under `seccompProfile` with a `type` field. Option D is wrong because it uses `seccomp: type: RuntimeDefault` as a flat key-value pair, which is invalid YAML structure; the correct nesting requires `seccompProfile` as an intermediate key.

Full explanation →

564

MCQmedium

A pod named 'web' is in a CrashLoopBackOff state. You suspect the application is failing due to a configuration error. You want to see the logs from the previous instance of the container. Which command should you use?

A.kubectl logs web

B.kubectl logs -f web

C.kubectl logs web --previous

D.kubectl describe pod web

AnswerC

kubectl logs web --previous is the correct approach because it retrieves the captured output from the last terminated container instance before the restart. When a container is in CrashLoopBackOff, the current container may crash too quickly to produce useful logs, but the previous instance's logs contain the error or stack trace that explains the failure. This flag directly targets the most recent failed container, which is the standard diagnostic step for this scenario.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container in a pod that has restarted. Since the pod is in CrashLoopBackOff, the current container has likely crashed and a new one has started; `--previous` shows the logs from the terminated container that caused the crash, helping diagnose the configuration error.

Exam trap

The trap here is that candidates assume `kubectl logs` alone shows all logs, but they forget that a crashed container's logs are only accessible with `--previous`, and they may mistakenly choose `kubectl describe pod` thinking it includes logs.

How to eliminate wrong answers

Option A is wrong because `kubectl logs web` only shows logs from the currently running container, which may be empty or unhelpful if the container has already crashed and restarted. Option B is wrong because `kubectl logs -f web` streams logs from the current container in real-time, but does not show logs from the previous terminated instance. Option D is wrong because `kubectl describe pod web` provides pod metadata, events, and status, but does not show container logs, which are needed to see the application error output.

Full explanation →

565

MCQmedium

You create a Service with the following manifest. What is the effect? service.yaml: apiVersion: v1 kind: Service metadata: name: ext-svc spec: type: ExternalName externalName: db.example.com

A.The service is a CNAME alias for db.example.com

B.The service gets a ClusterIP and forwards to db.example.com

C.The service creates a load balancer pointing to db.example.com

D.The service selects pods with label app: ext

AnswerA

An ExternalName service is a special Kubernetes service type that, instead of provisioning a ClusterIP or endpoints, writes a CNAME record into the cluster's DNS (CoreDNS) pointing to the external FQDN db.example.com. When a pod resolves the service's DNS name (e.g., my-service.default.svc.cluster.local), the DNS server returns a canonical answer directing the client to db.example.com directly. Because it is purely a DNS-level alias, no network proxy, selector, or load balancer is involved.

Why this answer

A Service of type `ExternalName` creates a DNS CNAME record in the cluster's DNS (e.g., CoreDNS) that maps the Service name `ext-svc` to the external DNS name `db.example.com`. When a Pod resolves `ext-svc`, it receives the canonical name `db.example.com` directly, with no proxy, ClusterIP, or pod selection involved.

Exam trap

The trap here is that candidates often assume all Services must have a ClusterIP or select pods, but `ExternalName` is a special type that operates purely at the DNS level with no networking objects created.

How to eliminate wrong answers

Option B is wrong because an `ExternalName` Service does not get a ClusterIP; it returns a CNAME record instead of an A/AAAA record, so no IP-based forwarding occurs. Option C is wrong because `ExternalName` does not provision any load balancer; it is purely a DNS-level alias, unlike `LoadBalancer` type which creates an external LB. Option D is wrong because `ExternalName` Services have no selector; they are designed to point to external DNS names, not to select pods via labels.

Full explanation →

566

MCQmedium

You need to run a database migration as a container before the main application container starts. Which Kubernetes concept should you use?

A.Job

B.Init container

C.Sidecar container

D.Ephemeral container

AnswerB

An init container is defined in the same pod spec as the application and runs sequentially to completion before any main container starts. The kubelet executes init containers in order, and the main containers are blocked until all init containers exit successfully. This makes it the correct, native way to run a database migration as a prerequisite: the app container does not even start until the migration container finishes.

Why this answer

Init containers run sequentially before the main application container starts and are designed for setup tasks like database migrations. They complete successfully before any regular containers in the Pod begin, ensuring the migration finishes before the main app starts.

Exam trap

The trap here is that candidates confuse init containers with Jobs, thinking both run to completion, but Jobs are independent objects while init containers are tightly coupled to a Pod's lifecycle and must complete before the main container starts.

How to eliminate wrong answers

Option A is wrong because a Job is a standalone resource that runs a task to completion independently of a Pod's lifecycle, not as a prerequisite for a specific Pod's main container. Option C is wrong because a sidecar container runs alongside the main container, not before it, and is used for supporting functions like logging or proxying. Option D is wrong because an ephemeral container is an ad-hoc container injected into a running Pod for debugging, not for pre-start initialization.

Full explanation →

567

MCQmedium

A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?

A.The pod uses the default service account token from the namespace

B.The service account token is mounted but not updated

C.The pod cannot communicate with the Kubernetes API

D.The service account token is not mounted into the pod

AnswerD

Setting automountServiceAccountToken to false in the pod spec tells the kubelet not to project the namespace's default service account token into the pod. As a result, no token appears under /var/run/secrets/kubernetes.io/serviceaccount, and the pod has no automatic bearer credentials for API requests. This is a deliberate security hardening measure for workloads that do not require Kubernetes API access, limiting the blast radius if the pod is compromised.

Why this answer

Setting `automountServiceAccountToken: false` in a Pod spec explicitly prevents the automatic mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling it means the token is not present in the container filesystem, so the Pod cannot authenticate to the Kubernetes API using that default mechanism.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken: false` with disabling API access entirely, but it only disables the automatic token mount—the pod can still use other authentication methods to reach the API.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: false` does not cause the pod to use the default service account token; it prevents any token from being mounted. Option B is wrong because the token is not mounted at all, so there is no token to be updated or not updated. Option C is wrong because while the pod cannot use the default mounted token for API communication, it can still communicate with the Kubernetes API if it uses an alternative authentication method (e.g., a custom token injected via a volume or a client certificate).

Full explanation →

568

MCQhard

You create a headless service with 'clusterIP: None' for a StatefulSet. How does a client discover the individual pod IPs?

A.DNS returns multiple A records for the service name, each pointing to a pod IP

B.The service returns the pod's hostname from the StatefulSet

C.An Ingress controller must be configured to expose each pod

D.The service provides a virtual IP that load balances among pods

AnswerA

A headless Service (clusterIP: None) removes the cluster-wide virtual IP, and CoreDNS creates an A record for every Ready pod that matches the Service's label selector. In a StatefulSet, each pod receives a stable hostname based on its ordinal, but the Service name itself returns a collection of A records containing the individual pod IPs. Clients can then connect directly to a chosen pod without any proxy involvement.

Why this answer

A is correct because a headless service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS is configured to return multiple A records directly for the service name, each pointing to the IP address of a pod in the StatefulSet. This allows clients to discover and connect to individual pod IPs, which is essential for stateful applications where each pod has a unique identity.

Exam trap

The trap here is that candidates confuse headless services with regular ClusterIP services, assuming DNS returns a single virtual IP or that load balancing is still in effect, when in fact headless services expose individual pod IPs directly via DNS.

How to eliminate wrong answers

Option B is wrong because a headless service does not return the pod's hostname; DNS returns A records with pod IPs, and the pod's hostname is derived from the StatefulSet name and ordinal, not from the service. Option C is wrong because an Ingress controller is used for HTTP/HTTPS traffic routing and is not required for pod IP discovery via DNS; headless services work at the network layer without Ingress. Option D is wrong because a headless service explicitly sets clusterIP: None, which disables virtual IP and load balancing; that behavior is for regular ClusterIP services, not headless ones.

Full explanation →

569

Multi-Selecthard

Which THREE of the following are true about NetworkPolicy? (Select 3)

Select 3 answers

A.Multiple NetworkPolicies are additive

B.NetworkPolicy can select pods in other namespaces using namespaceSelector

C.NetworkPolicy can control traffic to Services

D.If no NetworkPolicy selects a pod, then that pod is allowed all traffic

E.NetworkPolicy is a cluster-scoped resource

AnswersA, B, D

NetworkPolicies are evaluated as a union: when multiple NetworkPolicy objects select the same pod, every rule from every selected policy is combined, and an allow rule in any one policy will permit that traffic even if another policy does not mention it. This means the effective policy is the sum of all allow rules, not an intersection. Traffic not explicitly allowed by any of the aggregated rules remains denied once isolation is triggered.

Why this answer

Kubernetes NetworkPolicy rules are additive: if multiple policies select the same pod, the effective network rules are the union of all rules from all policies. This means that if any policy allows ingress or egress traffic on a given port/protocol, that traffic is permitted, even if another policy does not explicitly allow it. This additive behavior is defined in the Kubernetes networking specification and is critical for correctly combining policies from different teams or layers.

Exam trap

A common misconception is that NetworkPolicy is cluster-scoped or that it can control traffic to Services directly. In reality, NetworkPolicy only applies to Pod endpoints, not to the Service virtual IP.

Full explanation →

570

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Deployment named 'web' as a Service?

Select 2 answers

A.kubectl expose deployment web --port=80

B.kubectl port-forward deployment/web 8080:80

C.Apply a Service YAML with selector matching the deployment's pod labels

D.kubectl run web --image=nginx --port=80

E.kubectl create service clusterip web --tcp=80:80

AnswersA, C

kubectl expose deployment web --port=80 creates a Service of type ClusterIP by default, using the deployment's selector (pod template labels) to target the pods. It validates the deployment exists and uses the container port if --target-port not specified, defaulting to --port. This is a declarative-ish imperative command that creates a Service resource, exposing the deployment's pods to other cluster clients.

Why this answer

`kubectl expose deployment web --port=80` creates a Service that automatically selects Pods based on the labels defined in the Deployment's pod template. This command generates a ClusterIP Service that maps port 80 on the Service to the target port (defaulting to the same port) on the selected Pods, providing a stable network endpoint for the Deployment's replicas.

Exam trap

The CKAD exam often tests the distinction between creating a Service versus exposing an existing workload, so the trap here is that candidates may confuse `kubectl create service` (which requires explicit selector configuration) with `kubectl expose` (which automatically derives the selector from the resource), leading them to incorrectly select option E as a valid method.

Full explanation →

571

MCQmedium

A developer wants to tag a local image 'myapp:latest' with the tag 'v1.0.0' for pushing to a registry. Which command does this?

A.docker push myapp:v1.0.0

B.docker tag myapp:latest myapp:v1.0.0

C.kubectl tag myapp:latest myapp:v1.0.0

D.kubectl set image myapp:v1.0.0

AnswerB

docker tag creates an additional tag for an existing local image without altering the underlying image layers or content. Its syntax is 'docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]', so 'docker tag myapp:latest myapp:v1.0.0' assigns v1.0.0 as a new alias to the same image ID as the latest tag. This is the standard way to version a local image before pushing or referencing it outside the local daemon. The original latest tag remains intact, and both tags now point to the same image digest.

Why this answer

The `docker tag` command is used to tag an existing local image with a new tag. After tagging, the image can be pushed to a registry using `docker push`. There is no `kubectl tag` command; Kubectl does not manage local image tagging. `kubectl set image` is used to update the image of a deployment, not to tag a local image.

Exam trap

The trap is that candidates might think they need to use kubectl for image operations, but tagging a local image is a Docker operation. Also, they might confuse `kubectl set image` with tagging, but that command updates a deployment's container image, not a local image tag.

How to eliminate wrong answers

Option A is wrong because `docker push` uploads an image to a registry, but it does not create a new tag; it would attempt to push an image tagged `myapp:v1.0.0` that does not exist locally. Option C is wrong because `kubectl tag` is not a valid kubectl command; kubectl does not have a `tag` subcommand for Docker images. Option D is wrong because `kubectl set image` is used to update the container image of a Kubernetes resource (e.g., a deployment), not to tag a local Docker image.

Full explanation →

572

MCQeasy

What is the difference between 'kubectl apply' and 'kubectl create'?

A.'kubectl apply' only works with Deployments, while 'kubectl create' works with all resources

B.'kubectl apply' is for creating resources, 'kubectl create' is for updating

C.There is no difference

D.'kubectl apply' can be used to create and update resources; 'kubectl create' only creates new resources

AnswerD

This is correct: 'kubectl apply' provides declarative management—it creates a resource if absent and updates it if present by calculating a PATCH based on the object's live state and its stored last-applied configuration. 'kubectl create' is imperative and only performs an initial POST, failing with an error if the resource already exists. Because 'apply' knows the last-applied state, it supports partial updates, while 'create' does not.

Why this answer

'kubectl apply' is declarative: it creates or updates a resource to match the provided configuration. 'kubectl create' is imperative: it creates a new resource and will fail if the resource already exists.

Full explanation →

573

MCQhard

A CronJob is configured with concurrencyPolicy: Forbid. The scheduled job takes longer than the interval between schedules to complete. What happens when the next scheduled time arrives while the previous job is still running?

A.The running job is killed to make room for the new one

B.The new job starts immediately, overriding the running one

C.The CronJob controller skips the new execution and logs a warning

D.The new job is queued and starts after the running job completes

AnswerC

When the scheduler fires and concurrencyPolicy: Forbid is set, the CronJob controller inspects the CronJob's .status.active list for Job references that still exist and have not completed. If at least one is found, the controller skips creating a new Job and emits an event (often surfaced as a warning, e.g., 'skipped' or 'already active') to record the missed schedule. No retry is made at that point; the next scheduled time governs future executions.

Why this answer

When `concurrencyPolicy: Forbid` is set, the CronJob controller ensures that only one instance of the job runs at a time. If the previous job is still running when the next scheduled time arrives, the controller skips the new execution entirely and logs a warning (e.g., 'job already running'). This prevents overlapping executions, which is critical for workloads that must not run concurrently.

Exam trap

The trap here is that candidates often assume Kubernetes will queue or delay the job (Option D) because that seems logical, but the CronJob controller does not implement queuing — it strictly follows the concurrencyPolicy (Allow, Forbid, or Replace) without any built-in retry or backlog mechanism.

How to eliminate wrong answers

Option A is wrong because the CronJob controller does not kill running jobs when concurrencyPolicy is Forbid; it simply skips the new execution. Option B is wrong because the new job does not start immediately or override the running one; the controller respects the Forbid policy and does not launch a second job. Option D is wrong because the controller does not queue jobs; it either allows concurrent runs (Allow), replaces the running job (Replace), or skips the new one (Forbid) — queuing is not a supported behavior.

Full explanation →

574

MCQeasy

In a Dockerfile, what is the difference between CMD and ENTRYPOINT?

A.CMD always runs, ENTRYPOINT can be overridden

B.There is no difference; they are interchangeable

C.ENTRYPOINT defines the executable and CMD provides default arguments

D.CMD is used for shell form, ENTRYPOINT for exec form

AnswerC

Correct: ENTRYPOINT sets the main executable for the container, and CMD merely supplies default arguments that can be replaced at runtime. For example, `ENTRYPOINT ["nginx"]` with `CMD ["-g", "daemon off;"]` starts nginx and allows you to run `docker run nginx -t` to test config, where `-t` replaces CMD entirely. If you override with `docker run nginx -v`, the ENTRYPOINT stays `nginx` and receives `-v`, not CMD. This separation gives image authors a stable command with flexible defaults.

Why this answer

C is correct because in a Dockerfile, ENTRYPOINT specifies the executable that will always run when the container starts, while CMD provides default arguments that can be overridden. When both are defined, CMD arguments are appended to the ENTRYPOINT command, allowing flexible default behavior that users can modify at runtime via the command line.

Exam trap

The trap here is that candidates often confuse CMD and ENTRYPOINT as interchangeable or think CMD always runs, but the CKAD exam tests the precise relationship where ENTRYPOINT defines the executable and CMD provides default arguments that can be overridden.

How to eliminate wrong answers

Option A is wrong because CMD can be overridden by providing command-line arguments at container startup, while ENTRYPOINT is the instruction that always runs unless explicitly overridden with the --entrypoint flag. Option B is wrong because CMD and ENTRYPOINT have distinct roles: ENTRYPOINT sets the main executable, and CMD supplies default arguments or a default command if ENTRYPOINT is not defined. Option D is wrong because both CMD and ENTRYPOINT support both shell form and exec form; the choice of form affects signal handling and shell processing, not the distinction between the two instructions.

Full explanation →

575

MCQeasy

A developer needs to expose a database password to a Pod as an environment variable, securely. What should they do?

A.Hardcode the password in the Pod YAML

B.Store the password in a ConfigMap and use configMapKeyRef

C.Create a Secret and use secretKeyRef in the env definition

D.Use a ConfigMap with binaryData field

AnswerC

Creating a Secret and injecting it with secretKeyRef is the correct pattern for exposing a database password to a pod. Secrets are a dedicated API object for sensitive data; while they are only base64-encoded by default, you can enable encryption at rest for Secret objects in etcd, and they have granular RBAC controls to limit access. The secretKeyRef field in the env definition tells Kubernetes to read a specific key from a specified Secret and expose it as an environment variable, keeping the plaintext value out of the Pod YAML. This also makes rotation and secret lifecycle management much easier than hardcoding.

Why this answer

Kubernetes Secrets are the recommended mechanism for storing sensitive data like passwords. By referencing the Secret's key via `secretKeyRef` in the `env` definition of a Pod, the password is injected as an environment variable without being exposed in the Pod manifest or stored in plaintext. This approach ensures the data is base64-encoded at rest (and can be encrypted at rest with etcd encryption) and avoids the security risks of hardcoding or using ConfigMaps for secrets.

Exam trap

The trap here is that candidates confuse ConfigMaps with Secrets, thinking that `binaryData` or `configMapKeyRef` can securely store sensitive data, when in fact ConfigMaps lack encryption and access control mechanisms that Secrets provide.

How to eliminate wrong answers

Option A is wrong because hardcoding the password in the Pod YAML exposes the credential in plaintext in version control and manifests, violating security best practices. Option B is wrong because ConfigMaps are designed for non-sensitive configuration data; storing a password in a ConfigMap leaves it unencrypted and accessible to anyone with cluster access, and `configMapKeyRef` does not provide the security guarantees needed for secrets. Option D is wrong because while `binaryData` in a ConfigMap can store binary data, it still does not provide encryption or access control; ConfigMaps are not intended for secrets, and using `binaryData` does not make the data secure.

Full explanation →

576

Drag & Dropmedium

Arrange the steps to create a ConfigMap from a file and mount it as a volume in a Pod.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Create ConfigMap first, then define Pod with volume and volumeMount, apply, and verify.

Full explanation →

577

MCQhard

You have a Service named 'app-service' in namespace 'default'. You want a pod in namespace 'monitoring' to resolve the service DNS name. What is the correct fully qualified domain name (FQDN)?

A.app-service.default.cluster.local

B.app-service.svc.default.cluster.local

C.app-service.cluster.local.default.svc

D.app-service.default.svc.cluster.local

AnswerD

Correct answer. Kubernetes DNS uses the format <service-name>.<namespace>.svc.<cluster-domain>, and the default cluster domain is 'cluster.local'. Thus 'app-service' is the service, 'default' is the namespace, 'svc' is the fixed service record marker, and 'cluster.local' is the cluster's DNS suffix. This FQDN is exactly what CoreDNS resolves to the service's ClusterIP.

Why this answer

The standard FQDN for a Kubernetes Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`. This allows a pod in any namespace (including 'monitoring') to resolve the service by appending the cluster's DNS suffix. The DNS query for `app-service.default.svc.cluster.local` will be handled by CoreDNS (or kube-dns) and return the cluster IP of the service.

Exam trap

The trap here is that candidates often forget the `.svc` subdomain or misplace it, because they assume the namespace directly follows the service name without the intermediate `.svc` component.

How to eliminate wrong answers

Option A is wrong because it omits the mandatory `.svc` subdomain, which is required in the FQDN to distinguish service DNS records from pod DNS records. Option B is wrong because it places `.svc` before the namespace, breaking the correct hierarchical order of `<service>.<namespace>.svc.cluster.local`. Option C is wrong because it reverses the order entirely, placing `.cluster.local` before `.default.svc`, which does not match the Kubernetes DNS specification.

Full explanation →

578

MCQeasy

You want to see a list of all events in the 'default' namespace, sorted by timestamp. Which command should you use?

A.kubectl describe events

B.kubectl get pods

C.kubectl get events

D.kubectl logs --all-containers

AnswerC

kubectl get events directly queries the events API and is the idiomatic way to list all events in the current namespace. It returns a sorted table (by timestamp) containing columns like LAST SEEN, TYPE, REASON, OBJECT, and MESSAGE, giving a complete but concise view of cluster activity. This is the correct answer because it gives exactly the requested information.

Why this answer

`kubectl get events` retrieves all events in the current namespace (default) and, by default, sorts them by the `lastTimestamp` field in ascending order, which is the timestamp of the event. This command directly answers the requirement to list events sorted by timestamp without additional flags.

Exam trap

The trap here is that candidates confuse `kubectl describe events` with `kubectl get events`, assuming the `describe` verb provides a sorted list, but `describe` does not sort by timestamp and may omit events due to pagination limits.

How to eliminate wrong answers

Option A is wrong because `kubectl describe events` shows detailed information about events but does not sort them by timestamp; it groups events by resource and may truncate the list. Option B is wrong because `kubectl get pods` lists pods, not events, and has no timestamp sorting relevant to events. Option D is wrong because `kubectl logs --all-containers` retrieves container logs, not events, and logs are not sorted by event timestamps.

Full explanation →

579

MCQmedium

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

A.kubectl describe pod pod-name

B.kubectl logs pod-name -f

C.kubectl debug -it pod-name --image=busybox

D.kubectl exec -it pod-name -- /bin/sh

AnswerD

kubectl exec -it pod-name -- /bin/sh attaches directly to the primary container's process namespace and starts an interactive shell there. The -i flag keeps stdin open, and -t allocates a pseudo-TTY, giving you a real terminal session. This lets you run commands such as ps, cat /proc/1/cmdline, lsof, and netstat inside the exact runtime where the application is hanging, enabling direct inspection and troubleshooting of the live process. It is the only option that provides an interactive shell within the existing, running container.

Why this answer

`kubectl exec -it pod-name -- /bin/sh` opens an interactive shell inside the running container, allowing you to inspect processes, check network listeners, and debug the application directly. This is the standard command for gaining shell access to a container in Kubernetes.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which creates a new ephemeral container), and they may choose option C thinking it provides interactive access, but it does not attach to the original application container's process space.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod` shows pod metadata, events, and status but does not provide an interactive shell or allow process inspection inside the container. Option B is wrong because `kubectl logs -f` streams container logs, which is useful for viewing output but does not give you an interactive shell to run commands or inspect processes. Option C is wrong because `kubectl debug -it pod-name --image=busybox` creates a separate ephemeral container for debugging, not an interactive shell inside the original application container; it is used when the container image lacks debugging tools or the container is crashing, but the question specifies the pod is running and you need to inspect the existing application process.

Full explanation →

580

Multi-Selecthard

Which THREE statements about ResourceQuota are correct? (Select 3)

Select 3 answers

A.ResourceQuota can specify both requests and limits for compute resources

B.ResourceQuota can limit the maximum CPU limit for a single pod

C.ResourceQuota can limit the total number of ConfigMaps in a namespace

D.ResourceQuota applies to all pods in a namespace

E.ResourceQuota applies across all namespaces

AnswersA, C, D

ResourceQuota definitions support separate hard limits for compute requests and limits, such as requests.cpu, requests.memory, limits.cpu, and limits.memory. These aggregate values are enforced across all pods in the namespace, so the total requested or limited resources cannot exceed the configured caps. This granularity lets administrators distinguish between guaranteed reservation and maximum usage.

Why this answer

A ResourceQuota can specify both `requests` and `limits` for compute resources such as CPU and memory. This allows the quota to enforce constraints on the minimum requested resources and the maximum allowed usage across all pods in a namespace, ensuring fair resource distribution and preventing resource exhaustion.

Exam trap

The trap here is that candidates often confuse ResourceQuota's aggregate namespace-level enforcement with per-pod limits, which are actually handled by LimitRange, not ResourceQuota.

Full explanation →

581

Multi-Selecteasy

Which TWO Service types allow external access to pods from outside the Kubernetes cluster? (Select 2)

Select 2 answers

A.Headless

B.NodePort

C.ClusterIP

D.ExternalName

E.LoadBalancer

AnswersB, E

A NodePort service exposes a specific static port (30000–32767) on every cluster node’s IP address, forwarding inbound traffic from that port to the target pods. This mechanism satisfies the stem’s constraint of enabling external access from outside the cluster because any external client can reach the service by targeting `<NodeIP>:<NodePort>`, bypassing the cluster-internal network boundary.

Why this answer

NodePort is correct because it exposes a service on a static port on each node's IP address, allowing external traffic to reach the service by targeting any node's IP and that port. This works by opening a high-range port (30000-32767) on all nodes, which forwards traffic to the ClusterIP service and then to the pods.

Exam trap

The CKAD exam often tests the misconception that ClusterIP or Headless services can be accessed externally, when in fact only NodePort and LoadBalancer (and Ingress, though not listed) provide external access without additional configuration.

Full explanation →

582

MCQmedium

A user wants to create a Kubernetes Secret for storing Docker registry credentials (username and password). Which type of Secret should they use?

A.kubernetes.io/tls

B.Opaque

C.kubernetes.io/dockerconfigjson

D.kubernetes.io/basic-auth

AnswerC

kubernetes.io/dockerconfigjson is the canonical secret type for Docker registry authentication, storing the entire Docker config file (typically generated by `docker login`) in a data field named `.dockerconfigjson`. This file contains `auths` entries with base64-encoded `username:password` tokens for each registry. When this secret is attached to a Pod via `imagePullSecrets`, the kubelet decodes it and uses the embedded credentials to pull private images exactly as Docker does.

Why this answer

`kubernetes.io/dockerconfigjson` is the dedicated Secret type for storing Docker registry credentials in the format expected by `docker login`. It automatically encodes the username and password into a `.dockerconfigjson` field, which is used by Kubernetes to pull images from private registries. This type is required when referencing a `imagePullSecret` in a Pod spec.

Exam trap

The trap here is that candidates often choose `Opaque` (Option B) because they think any secret can be used for Docker credentials, but the CKAD exam expects you to know that only `kubernetes.io/dockerconfigjson` provides the correct format and automatic integration with image pull secrets.

How to eliminate wrong answers

Option A is wrong because `kubernetes.io/tls` is used for TLS certificates and private keys, not for Docker registry credentials. Option B is wrong because `Opaque` is a generic secret type for arbitrary key-value pairs, but it does not provide the correct structure or automatic handling required by the container runtime for registry authentication. Option D is wrong because `kubernetes.io/basic-auth` is intended for HTTP basic authentication credentials (username/password for web services), not for Docker registry login data.

Full explanation →

583

MCQeasy

Which commands list all Helm releases in the current namespace? (Select all that apply)

A.helm list

B.helm get all

C.helm ls

D.helm status

AnswerA, C

`helm list` is the canonical Helm verb for enumerating releases in the current Kubernetes namespace. It queries Helm's stored release records (Secrets/ConfigMaps tagged with helm.sh/release.v1) and displays columns for release name, status, chart version, app version, and namespace, with options like `--all-namespaces` (`-A`) to expand scope and `--short` to print names only. Without `-A`, it respects the default namespace from kubeconfig or the `--namespace` flag.

Why this answer

Both `helm list` and its alias `helm ls` are valid commands to list all Helm releases in the current namespace. `helm get all` retrieves all information about a specific release, and `helm status` shows the status of a single release.

Exam trap

The CKAD exam tests that you know both `helm list` and its alias `helm ls` are acceptable. The trap is thinking only one is correct when both work. This is a multi-select question.

How to eliminate wrong answers

Option B is wrong because `helm get all` is not a valid Helm command; the correct command to retrieve all manifests of a specific release is `helm get manifest <release>`. Option C is wrong because while `helm ls` is a valid alias for `helm list` and would technically work, the question asks for the command that lists releases, and `helm ls` is simply a shorthand, not the primary command name; however, in the context of this question, both A and C are functionally correct, but the exam expects `helm list` as the canonical answer. Option D is wrong because `helm status` displays detailed status information for a single named release, not a list of all releases.

Full explanation →

584

MCQhard

An Ingress resource uses the annotation 'kubernetes.io/ingress.class: nginx'. However, traffic is not being routed. The cluster has multiple ingress controllers. What is the most likely cause?

A.The ingress controller is not installed.

B.The annotation is deprecated; use spec.ingressClassName instead.

C.The service backend doesn't exist.

D.TLS certificate is invalid.

AnswerB

The `kubernetes.io/ingress.class` annotation was deprecated when the `IngressClass` API resource and `spec.ingressClassName` field were introduced in Kubernetes v1.18, and it is completely ignored starting in v1.22. To specify the ingress controller, you must set `spec.ingressClassName` to the name of an `IngressClass` object, e.g., `spec.ingressClassName: nginx`. If both the annotation and the field are present, the field takes precedence, and the annotation has no effect.

Why this answer

The annotation `kubernetes.io/ingress.class` is deprecated in Kubernetes 1.18+ and removed in 1.25+. The correct approach is to use `spec.ingressClassName` in the Ingress spec, which references an `IngressClass` resource. Since the cluster has multiple ingress controllers, the deprecated annotation may be ignored or not processed by the intended controller, causing traffic not to be routed.

Exam trap

The trap here is that candidates assume the annotation still works because it was used in older versions, but the CKAD exam tests awareness of deprecation and the newer `spec.ingressClassName` field, especially in clusters with multiple ingress controllers.

How to eliminate wrong answers

Option A is wrong because the cluster has multiple ingress controllers, so at least one is installed; the issue is that the deprecated annotation may not be recognized by the intended controller. Option C is wrong because the question states traffic is not being routed, not that the service backend is missing; a missing backend would cause a different error (e.g., 503 or 404), not a complete lack of routing. Option D is wrong because an invalid TLS certificate would cause TLS handshake failures (e.g., 525 or certificate errors), not prevent traffic routing entirely; the Ingress would still route HTTP traffic or return a certificate error.

Full explanation →

585

MCQhard

During a canary deployment, you want to send 10% of traffic to the new version. You have two Deployments: 'app-stable' (version: stable) and 'app-canary' (version: canary). You use a Service with label selector 'app: myapp' and a second selector for version. How can you achieve the 10% traffic split?

A.Use an Ingress controller that supports canary deployments or a service mesh

B.Use a Service with multiple ports

C.Set the Service's sessionAffinity to distribute load

D.Scale app-canary to 1 replica and app-stable to 9 replicas, and use a single Service that selects both

AnswerA

Ingress controllers such as NGINX Ingress expose canary-specific annotations (e.g., nginx.ingress.kubernetes.io/canary-weight) that allow precise, percentage-based traffic splitting between two backend Services, while a service mesh like Istio provides similar fine-grained control through VirtualService and DestinationRule resources. This approach operates at the L7 routing layer, so it can deterministically send exactly 10% of requests to the canary version instead of relying on heuristics like replica counts or connection persistence.

Why this answer

Kubernetes Services alone cannot perform weighted traffic splitting based on replica counts; they use round-robin load balancing at the pod level. To achieve a precise 10% traffic split, you need an Ingress controller (e.g., NGINX Ingress with canary annotations) or a service mesh (e.g., Istio with VirtualService) that supports weighted routing between two different Services or subsets. This allows you to direct a specific percentage of traffic to the canary version independently of replica counts.

Exam trap

A common pitfall is the misconception that scaling replicas in proportion to desired traffic split (e.g., 1 canary and 9 stable) will automatically give a 10% traffic split via a single Service. However, Kubernetes Service load balancing is not weighted by replica count and does not guarantee precise percentages.

How to eliminate wrong answers

Option B is wrong because multiple ports on a Service are used to expose different container ports, not to split traffic between different versions of an application. Option C is wrong because sessionAffinity (e.g., ClientIP) ensures a client sticks to the same pod, but it does not control the proportion of traffic sent to different versions; it only affects session persistence. Option D is wrong because a single Service with a selector that matches both Deployments (e.g., 'app: myapp') will distribute traffic equally among all matching pods via round-robin, regardless of replica counts; the Service does not weight traffic by replica numbers, so 1 canary pod and 9 stable pods would still result in roughly 10% of requests hitting the canary only if the load balancer is perfectly random, but Kubernetes Service does not guarantee a precise percentage and can vary with request timing and pod readiness.

Full explanation →

586

MCQhard

You need to debug a pod that is running but not serving traffic. You want to add a temporary container with networking tools to the pod. Which command should you use?

A.kubectl run debug --image=busybox -it --restart=Never -- /bin/sh

B.kubectl attach mypod

C.kubectl exec -it mypod -- /bin/sh

D.kubectl debug mypod --image=busybox -it

AnswerD

kubectl debug mypod --image=busybox -it adds an ephemeral container to the same pod, sharing the pod's network namespace, filesystem mounts, and IPC. This gives you a fresh multitool environment (busybox) without disturbing the original container, ideal for inspecting network endpoints, DNS, or routing from the pod's point of view. It is the standard, non-invasive way to debug a running pod that is not serving traffic as expected.

Why this answer

`kubectl debug` allows you to add an ephemeral container (a temporary container with networking tools) to an existing running pod without restarting it. This is the only command that directly injects a new container into the pod's network namespace, enabling debugging of network issues while the original container continues running.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which adds a new container), and they forget that `kubectl exec` requires the target container to have the necessary tools installed, which is often not the case in production images.

How to eliminate wrong answers

Option A is wrong because `kubectl run debug --image=busybox -it --restart=Never -- /bin/sh` creates a completely new, standalone pod, not a temporary container attached to the existing pod. Option B is wrong because `kubectl attach mypod` attaches to the main process of an existing container in the pod, but it does not add a new container or provide networking tools; it only connects to the container's stdin/stdout/stderr. Option C is wrong because `kubectl exec -it mypod -- /bin/sh` runs a command inside an existing container of the pod, but if that container lacks networking tools (e.g., a minimal distroless image), you cannot install them without modifying the image.

Full explanation →

587

MCQhard

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

A.runAsUser: 1000

B.runAsGroup: 1000

C.readOnlyRootFilesystem: true

D.allowPrivilegeEscalation: false

AnswerB

The requirement only specifies a non-root user, not a specific group. runAsGroup, if omitted, leaves the container's primary GID unchanged from the image or the user's default group, which does not affect the process's non-root status. Since no group requirement is stated, runAsGroup is optional and therefore the correct answer to a question asking which setting is not required.

Why this answer

(runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Exam trap

The trap here is that candidates often assume runAsGroup is mandatory alongside runAsUser for non-root execution, but the CKAD exam tests that only the user ID is required unless a specific group is explicitly needed.

How to eliminate wrong answers

Option A is wrong because runAsUser: 1000 is required to run the container as a non-root user with UID 1000, directly addressing the requirement. Option C is wrong because readOnlyRootFilesystem: true is required to mount the container's filesystem as read-only, fulfilling that specific requirement. Option D is wrong because allowPrivilegeEscalation: false is required to prevent privilege escalation, which is explicitly stated in the requirements.

Full explanation →

588

MCQmedium

A Helm chart is installed with the command 'helm install myapp ./mychart'. You need to upgrade the release with new values from a file 'prod-values.yaml'. Which command is correct?

A.helm upgrade myapp ./mychart --values prod-values.yaml

B.helm upgrade ./mychart prod-values.yaml --release myapp

C.helm upgrade --install myapp ./mychart -f prod-values.yaml

D.helm upgrade myapp -f prod-values.yaml

AnswerA

Helm's upgrade subcommand follows the positional contract `helm upgrade [RELEASE] [CHART]`, so `myapp` is the release being upgraded and `./mychart` is the chart to deploy. The `--values prod-values.yaml` flag (or `-f`) passes the production overrides file, which is merged into the release's configuration. This is the exact, minimal, and idempotent command for upgrading an existing release named `myapp` from the local chart directory using the specified values file.

Why this answer

`helm upgrade myapp ./mychart --values prod-values.yaml` explicitly specifies the release name (`myapp`), the chart path (`./mychart`), and the values file (`--values prod-values.yaml`). This is the standard syntax for upgrading a Helm release with custom values, where `--values` (or `-f`) merges the provided YAML file over the default chart values.

Exam trap

The CKAD exam often tests the exact positional syntax of Helm commands, and the trap here is that candidates may forget that `helm upgrade` requires both the release name and the chart path as positional arguments, leading them to pick options that omit the chart path (like D) or misplace arguments (like B).

How to eliminate wrong answers

Option B is wrong because it incorrectly places the chart path (`./mychart`) before the values file and uses `--release myapp` instead of the positional release name argument; Helm expects the release name as the first argument after `upgrade`, not a flag. Option C is wrong because `--install` is unnecessary for an upgrade (it would create the release if missing, but the question only asks to upgrade an existing release) and the command still works but is not the minimal correct answer; however, the primary issue is that it adds an extra flag not required by the scenario. Option D is wrong because it omits the chart path (`./mychart`), which is mandatory for `helm upgrade` to know which chart to apply; without it, Helm will fail with an error about missing chart reference.

Full explanation →

589

Multi-Selecteasy

Which TWO of the following are valid non-interactive methods to update a Deployment's image?

Select 2 answers

A.kubectl replace -f deployment.yaml

B.kubectl edit deployment/myapp and change the image field

C.kubectl rollout image deployment/myapp mycontainer=nginx:1.21

D.kubectl set image deployment/myapp mycontainer=nginx:1.21

E.kubectl create -f deployment.yaml

AnswersA, D

kubectl replace with an updated YAML file is a declarative update: it submits the entire Deployment manifest to the API server, replacing the existing resource representation. This is a valid method because the file contains the new image, and the server applies it atomically. It differs from set image in that you must provide a full manifest rather than a targeted field change.

Why this answer

Option A (kubectl replace -f deployment.yaml) is correct because replace applies a full manifest non-interactively, so if the YAML file already contains the updated image, the Deployment's Pod template is replaced and a rollout is triggered without opening an editor. Option D (kubectl set image deployment/myapp mycontainer=nginx:1.21) is correct because kubectl set image is a purpose-built, non-interactive command that directly patches the named container's image in the Deployment spec, causing a new ReplicaSet rollout. Option B is not valid here because kubectl edit opens an interactive text editor, which contradicts the non-interactive requirement.

Option C is not valid because kubectl rollout does not have an 'image' subcommand; the correct subcommands are status, history, undo, restart, pause, and resume. Option E is not valid because kubectl create fails when the Deployment already exists and is not an update method.

Exam trap

CKAD often tests whether candidates confuse imperative update commands (`set image`, `replace`) with interactive ones (`edit`) or invent non-existent subcommands like `rollout image`.

Full explanation →

590

MCQeasy

Which probe type is used to determine if a container is ready to serve traffic?

A.Liveness probe

B.Readiness probe

C.Startup probe

D.Resource probe

AnswerB

A readiness probe determines whether the container is ready to accept traffic; if it fails, the pod is removed from the endpoints of all Services. This directly controls traffic routing, making it the correct probe type to determine if a container is ready to receive requests. It does not restart the container, but only influences Service endpoint membership, allowing traffic to resume when the probe succeeds again.

Why this answer

A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, the container is removed from the Service's endpoints, ensuring no requests are routed to an unready pod. This is defined in the PodSpec under `readinessProbe` and is essential for rolling updates and traffic management.

Exam trap

The trap here is that candidates confuse Liveness and Readiness probes, thinking both control traffic, but only the Readiness probe affects Service endpoints, while Liveness only triggers container restarts.

How to eliminate wrong answers

Option A is wrong because a Liveness probe checks if the container is still running (i.e., not deadlocked or crashed) and restarts it if it fails, but it does not control traffic routing. Option C is wrong because a Startup probe is used to delay Liveness and Readiness checks until the container has fully started, especially for slow-booting applications, but it does not directly determine traffic readiness. Option D is wrong because there is no standard 'Resource probe' in Kubernetes; resource management is handled via requests and limits, not probes.

Full explanation →

591

MCQeasy

Which command is used to undo the most recent rollout of a Deployment named 'myapp'?

A.kubectl rollout undo deployment myapp

B.kubectl rollout undo deployment myapp --to-revision=2

C.kubectl rollout status deployment myapp

D.kubectl rollback deployment myapp

AnswerA

This command reverts the Deployment to its previous revision, making the prior pod template the current desired state. It works by creating a new ReplicaSet from the last configuration and using the rolling update strategy to replace the current ReplicaSet, thereby undoing the most recent rollout.

Why this answer

`kubectl rollout undo deployment myapp` reverts the Deployment to the previous revision by default, effectively undoing the most recent rollout. This command uses the rollout history stored in the Deployment's annotations (e.g., `deployment.kubernetes.io/revision`) to identify and apply the prior ReplicaSet.

Exam trap

The trap here is that candidates confuse `kubectl rollout undo` with the non-existent `kubectl rollback` command, or assume `--to-revision=2` always undoes the most recent rollout, when in fact it targets a specific revision regardless of recency.

How to eliminate wrong answers

Option B is wrong because `--to-revision=2` explicitly rolls back to revision 2, not necessarily the most recent rollout; if the most recent rollout was revision 3, this would undo to revision 2, not the immediate previous state. Option C is wrong because `kubectl rollout status deployment myapp` only checks the current rollout progress and does not perform any undo operation. Option D is wrong because `kubectl rollback` is not a valid kubectl command; the correct verb is `rollout undo`, and `rollback` is a legacy term from older orchestration tools like Docker Compose or Kubernetes API extensions.

Full explanation →

592

MCQeasy

Which file prevents certain files from being copied into a Docker image during a build?

A..kubeignore

B.Dockerfile.ignore

C..dockerignore

D..gitignore

AnswerC

.dockerignore is the correct file: when running docker build, the Docker CLI reads .dockerignore from the root of the build context and excludes any matching files or directories from the context tar sent to the daemon. This prevents secrets, local caches, and unwanted files from being copied into image layers via COPY or ADD, and also shrinks the context to speed up the build. Patterns support globbing and negation with !.

Why this answer

The `.dockerignore` file is used to specify patterns for files and directories that should be excluded from the Docker build context when running `docker build`. This prevents unnecessary or sensitive files (e.g., `node_modules`, `.git`, secrets) from being sent to the Docker daemon and copied into the image, reducing build time and image size.

Exam trap

The trap here is that candidates confuse `.dockerignore` with `.gitignore` due to their similar purpose and syntax, but `.gitignore` has no effect on Docker builds, and the CKAD exam expects you to know the exact Docker-specific filename.

How to eliminate wrong answers

Option A is wrong because `.kubeignore` is not a standard file in Docker or Kubernetes; Kubernetes uses `.kubeignore` only in the context of `kubectl cp` operations to exclude files, not during Docker image builds. Option B is wrong because `Dockerfile.ignore` is not a recognized filename; Docker only supports `.dockerignore` for build context exclusion. Option D is wrong because `.gitignore` is used by Git to exclude files from version control, not by Docker to exclude files from the build context; while similar in syntax, `.gitignore` has no effect on Docker builds.

Full explanation →

593

MCQmedium

You are using Kustomize. Your kustomization.yaml file specifies a base and an overlay. You run: kubectl apply -k overlays/production. What happens?

A.It errors because -k expects a directory with kustomization.yaml.

B.It applies the base resources only.

C.It applies the merged result of base and overlay.

D.It applies the overlay resources only.

AnswerC

When you run kubectl apply -k overlays/production, kustomize reads the kustomization.yaml in that overlay directory, which typically lists the base directory as a resource. It then merges the base resources with overlay-specific patches, strategic merge patches, name prefixes, labels, or namespace changes, producing a single unified manifest set. This rendered output is sent to kubectl apply, which creates or updates the live cluster objects accordingly.

Why this answer

When you run `kubectl apply -k overlays/production`, Kustomize reads the `kustomization.yaml` in the specified directory, which references a base and an overlay. It then performs a strategic merge patch of the overlay's customizations (e.g., patches, namePrefix, commonLabels) onto the base resources, producing a single set of manifests that are applied to the cluster. This is the core purpose of Kustomize: to compose and customize resources without templating.

Exam trap

The trap here is that candidates might think `-k` applies only the contents of the specified directory (like `-f` does), but Kustomize always resolves the full overlay chain, including the base, so the result is a merged output, not just the overlay's files.

How to eliminate wrong answers

Option A is wrong because `-k` does not require a directory with a file named exactly `kustomization.yaml`; it expects a directory containing a `kustomization.yaml` (or `kustomization.yml` or `Kustomization`) file, and `overlays/production` is a valid directory that contains such a file. Option B is wrong because Kustomize always merges the overlay onto the base; it does not apply only the base resources when an overlay is specified. Option D is wrong because Kustomize does not apply only the overlay resources; it merges the overlay's modifications onto the base, and the base resources are always included in the final output.

Full explanation →

594

MCQeasy

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?

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

B.requests: memory: 2Gi, cpu: 500m; limits: memory: 2Gi, cpu: 500m

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

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

AnswerB

When memory and CPU requests are set identically to their limits, the pod belongs to the Guaranteed QoS class, which is the only class with the highest eviction priority. The node reserves exactly 2Gi of memory and 500m of CPU for scheduling, while the runtime caps actual usage at those same values, preventing memory overcommit and making the pod's resource behavior completely predictable. This matches the stated 2Gi requirement and ensures the application is never silently granted less or allowed to escape its quota.

Why this answer

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.

Exam trap

The trap here is that candidates often think setting only requests (Option A) or setting limits higher than requests (Option C) still gives Guaranteed QoS, but Kubernetes strictly requires requests == limits for all resources to achieve Guaranteed class.

How to eliminate wrong answers

Option A is wrong because it sets only requests without limits, which places the pod in the Burstable QoS class (since limits are not set, the pod can burst above requests). Option C is wrong because the limits exceed the requests (memory 4Gi > 2Gi, CPU 1 > 500m), which also results in Burstable QoS, not Guaranteed. Option D is wrong because the requests are lower than the limits (memory 1Gi < 2Gi, CPU 250m < 500m), again yielding Burstable QoS; additionally, the requests do not match the developer's requirement of 2Gi memory and 500m CPU.

Full explanation →

595

MCQeasy

Which command lists all the secrets in the current namespace?

A.kubectl get configmaps

B.kubectl describe secrets

C.kubectl list secrets

D.kubectl get secrets

AnswerD

The `kubectl get` verb is the standard way to list resources in Kubernetes, and `secrets` is the plural resource name for the Secret API object. Running `kubectl get secrets` in a namespace returns a table of all Secrets in that namespace, showing their name, type, and data size. To list Secrets in all namespaces, you would use `kubectl get secrets --all-namespaces`.

Why this answer

The correct command to list all secrets in the current namespace is `kubectl get secrets`. This command retrieves and displays all Secret resources in the namespace specified by the current context (or the `--namespace` flag). Secrets are stored in etcd as base64-encoded data and are managed via the Kubernetes API, and `kubectl get` is the standard verb for listing resources.

Exam trap

CNCF often tests the distinction between `get` and `describe` verbs, and candidates may confuse `kubectl describe secrets` (which shows details) with listing secrets, or they may incorrectly assume `kubectl list secrets` is a valid command due to familiarity with Linux `ls` or `list` commands.

How to eliminate wrong answers

Option A is wrong because `kubectl get configmaps` lists ConfigMap resources, not Secrets; ConfigMaps store non-sensitive configuration data, while Secrets store sensitive data like credentials. Option B is wrong because `kubectl describe secrets` shows detailed information about a specific Secret (or all Secrets if no name is given), but it does not produce a simple list of Secret names; it outputs verbose details including metadata and data keys. Option C is wrong because `kubectl list secrets` is not a valid kubectl command; the correct verb for listing resources is `get`, not `list`.

Full explanation →

596

MCQhard

You need to debug a pod that has no shell installed. You want to add a temporary container with debugging tools to the pod. Which command should you use?

A.kubectl debug mypod -it --image=busybox -- /bin/sh

B.kubectl run debug --image=busybox -it -- /bin/sh

C.kubectl debug mypod --image=busybox --target=debug -n default

D.kubectl exec -it mypod -- /bin/sh

AnswerA

kubectl debug with --image creates an ephemeral container inside the existing pod, sharing its process namespace and network, so busybox tools can inspect the running workload. This works when the original container lacks a shell, satisfying the debugging constraint.

Why this answer

`kubectl debug mypod -it --image=busybox -- /bin/sh` creates an ephemeral container in the existing pod `mypod`, attaching it interactively with a shell. This allows you to debug a pod that lacks a shell or debugging tools without modifying the original container's image or restarting the pod.

Exam trap

The trap here is that candidates confuse `kubectl debug` (which adds a container to an existing pod) with `kubectl run` (which creates a new pod), or mistakenly think `kubectl exec` can work on any container regardless of whether a shell is present.

How to eliminate wrong answers

Option B is wrong because `kubectl run debug --image=busybox -it -- /bin/sh` creates a completely new, standalone pod named `debug` rather than adding a container to the existing pod `mypod`. Option C is wrong because `--target=debug` is not a valid flag for `kubectl debug`; the `--target` flag is used for attaching to a specific container within a pod, not for specifying a debug image name. Option D is wrong because `kubectl exec -it mypod -- /bin/sh` attempts to run a shell inside an existing container, which fails if the container has no shell installed (e.g., a scratch-based image).

Full explanation →

597

MCQmedium

You have just applied a new Deployment configuration using 'kubectl apply -f deployment.yaml'. You want to see the latest revision number of the rollout. Which command should you run?

A.kubectl rollout status deployment/myapp

B.kubectl get deployment myapp -o yaml

C.kubectl describe deployment myapp

D.kubectl rollout history deployment/myapp

AnswerD

kubectl rollout history deployment/myapp is the dedicated command for displaying the rollout history of a Deployment. It lists each revision number, the change-cause annotation (if set), and the revision timestamps, directly derived from the underlying ReplicaSets created by the Deployment controller. This command provides a concise, numbered table that lets you compare revisions and identify which revision to roll back to, making it the correct and most direct way to see revision numbers in a deployment.

Why this answer

'kubectl rollout history deployment/<name>' shows revision history with revision numbers. The latest revision is shown as the most recent.

Full explanation →

598

MCQmedium

You have a Deployment 'web' with 'maxSurge: 25%' and 'maxUnavailable: 25%'. Current replicas is 4. You update the image. How many pods will be created at most during the rollout?

A.8

B.4

C.5

D.6

AnswerC

5 is correct because with a desired replica count of 4, the 25% maxSurge rounds up to exactly 1 additional pod. This brings the total possible pods during the rollout to 5 (4 desired + 1 surge), enabling the Deployment to create the new pod before scaling down the old ReplicaSet, thereby preserving availability.

Why this answer

With maxSurge: 25% and maxUnavailable: 25%, the maximum number of pods created during a rolling update is calculated as current replicas (4) plus the surge (25% of 4 = 1), resulting in up to 5 pods at any given time. The surge allows extra pods to be created before terminating old ones, ensuring availability while limiting the total to 5.

Exam trap

The trap here is that candidates often forget to add the surge pods to the current replica count, mistakenly thinking the surge replaces pods rather than being created in addition to them.

How to eliminate wrong answers

Option A is wrong because 8 pods would require a maxSurge of 100% (4 extra pods), not 25%. Option B is wrong because 4 pods ignores the surge entirely, assuming no extra pods are created during the rollout, which contradicts the maxSurge setting. Option D is wrong because 6 pods would require a maxSurge of 50% (2 extra pods), not 25%.

Full explanation →

599

Multi-Selectmedium

Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?

Select 2 answers

A.Use a Deployment with 'strategy.type: Recreate' and delete the old version before creating the new one.

B.Create a Deployment with two replicas and use a Service with session affinity to gradually shift traffic.

C.Use a Deployment with 'strategy.type: RollingUpdate' and set 'maxSurge: 100%' and 'maxUnavailable: 0%'.

D.Create two Services, one for blue and one for green. Initially point an ingress to the blue Service. Update the ingress to point to green after validation.

E.Create two Deployments with different labels (e.g., version: blue and version: green). Use a Service initially selecting blue. Update the Service selector to green after green is ready.

AnswersD, E

This is a valid blue-green pattern that uses two dedicated Services, one for each version, with an Ingress as the traffic switch. Initially the Ingress backend points to the blue Service; after the green version is fully tested and ready, you update the Ingress to route traffic to the green Service. This gives you a stable network endpoint for each environment and lets you roll back instantly by reverting the Ingress backend to blue. It is technically sound and demonstrates a clean separation between routing and application lifecycle.

Why this answer

Option D is correct because blue-green deployment requires two parallel environments and an atomic traffic switch: running separate blue and green Services and using an Ingress (or similar L7 router) to direct traffic to the blue Service, then updating the Ingress backend to the green Service after validation, achieves exactly that cutover without downtime. Option E is correct because two Deployments distinguished by labels (version: blue and version: green) with a Service whose selector initially matches blue, then is updated to match green once the green pods are Ready, is the canonical Kubernetes blue-green pattern using native Service selector switching. Option A is not blue-green because strategy.type: Recreate tears down the old version before starting the new one, causing downtime and providing no parallel green environment to validate.

Option B is not blue-green because session affinity on a single Service with two replicas does not create two distinct blue/green versions or an atomic traffic switch. Option C is not blue-green because a RollingUpdate with maxSurge: 100% and maxUnavailable: 0% is a progressive rollout of one version, not two coexisting environments with a controlled cutover.

Exam trap

CKAD often tests the misconception that a Deployment strategy (Recreate or RollingUpdate) constitutes blue-green, when in fact blue-green requires two parallel environments plus an atomic traffic switch via Service selector or Ingress backend.

Full explanation →

600

MCQhard

A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?

A.runAsUser: 1000

B.capabilities: drop: ["ALL"]

C.allowPrivilegeEscalation: false

D.readOnlyRootFilesystem: true

AnswerD

readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, meaning the container cannot write to any files in its root filesystem. This directly satisfies the security requirement that the container must run with a read-only root filesystem. Any attempt to write to the root filesystem will fail with a read-only file system error.

Why this answer

Setting `readOnlyRootFilesystem: true` in the container's `securityContext` enforces that the container's root filesystem is mounted as read-only, preventing any writes to the filesystem at the root level. This satisfies the security requirement by ensuring that even if a process is compromised, it cannot modify system binaries, configuration files, or other critical files within the container's root filesystem.

Exam trap

The trap here is that candidates often confuse security context fields that control process privileges (like `runAsUser` or `capabilities`) with filesystem mount restrictions, mistakenly thinking dropping capabilities or disabling privilege escalation will make the filesystem read-only.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets the user ID under which the container runs, but does not affect the writability of the root filesystem; it controls process privileges, not filesystem mount permissions. Option B is wrong because `capabilities: drop: ["ALL"]` removes all Linux capabilities from the container, which reduces kernel-level privileges but does not prevent writes to the root filesystem; the filesystem can still be written to unless explicitly mounted read-only. Option C is wrong because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not restrict filesystem write access; a non-privileged process can still modify files on a writable root filesystem.

Full explanation →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 526–600