Knowledge + Practice

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

991 questions total · 14pages · All types, answers revealed

Take a mock exam Exam hub

Page 8 of 14

526

MCQhard

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

A.Sidecar pattern (generic)

B.Adapter pattern

C.Ambassador pattern

D.Init container pattern

AnswerB

The adapter pattern modifies or transforms data from the main container to match external interfaces. Here, the sidecar converts logs to metrics.

Why this answer

Option A is correct. The adapter pattern transforms the main container's output (e.g., logs) into a format expected by an external system (e.g., Prometheus metrics). The sidecar pattern adds functionality without modifying the main container; ambassador patterns proxy external connections; init containers run before the main containers start.

Full explanation →

527

Multi-Selecthard

Which THREE of the following are valid ways to update a Deployment's container image in Kubernetes?

Select 3 answers

A.kubectl apply -f updated-deployment.yaml with the new image.

B.kubectl set image deployment/myapp myapp=nginx:1.20

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

D.kubectl rollout image deployment myapp nginx:1.20

E.kubectl edit deployment myapp and change the image in the editor.

AnswersA, B, E

Correct. Applying a modified YAML file updates the deployment.

Why this answer

Option A is correct because `kubectl apply -f updated-deployment.yaml` applies a declarative configuration that includes the new container image. When the Deployment manifest is updated with the new image and reapplied, Kubernetes performs a rolling update to gradually replace pods with the new image, ensuring zero downtime if configured correctly.

Exam trap

The trap here is that candidates may confuse `kubectl rollout` with `kubectl set image` or invent commands like `kubectl update` or `kubectl rollout image`, which do not exist in kubectl's command set.

Full explanation →

528

MCQhard

You have a Deployment that uses a ConfigMap. You update the ConfigMap, but the pods are not picking up the changes. What is the MOST efficient way to force the pods to use the new ConfigMap values without downtime?

A.Run 'kubectl rollout restart deployment/deployment-name'

B.Delete the pods manually and let the ReplicaSet recreate them

C.Delete the ConfigMap and recreate it with the same name

D.Edit the Deployment to add an annotation, triggering a rollout

AnswerA

This performs a rolling restart, updating pods with the new ConfigMap without downtime.

Why this answer

A is correct because `kubectl rollout restart deployment/deployment-name` triggers a new ReplicaSet and gracefully terminates old pods while creating new ones, which will mount the updated ConfigMap. This avoids downtime by leveraging the Deployment's rolling update strategy, ensuring the new pods read the current ConfigMap data from the volume mount or environment variable reference.

Exam trap

The trap here is that candidates assume ConfigMap updates are automatically reflected in running pods, but Kubernetes only refreshes mounted volumes after a sync interval (and never for environment variables), so a restart is required to pick up changes without downtime.

How to eliminate wrong answers

Option B is wrong because manually deleting pods causes the ReplicaSet to recreate them with the same old ConfigMap data, as the ConfigMap reference in the Pod template hasn't changed; it does not force a refresh. Option C is wrong because deleting and recreating the ConfigMap with the same name does not update the pods' in-memory data or mounted files unless the pods are restarted; the pods continue to use the cached version from the initial mount. Option D is wrong because adding an annotation to the Deployment triggers a rollout only if the annotation change is part of a spec change that causes the Pod template hash to differ; a simple metadata annotation update without a corresponding pod template change does not trigger a rollout in Kubernetes.

Full explanation →

529

MCQhard

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

A.The service is configured to use a different port

B.The pod's node is cordoned

C.The liveness probe is failing and restarting the container

D.The readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open

AnswerD

Correct. A TCP socket check only confirms the port is open, not that the application is ready to serve HTTP traffic.

Why this answer

If the readiness probe passes, the pod should be in service endpoints. But if the probe passes incorrectly (e.g., TCP socket check succeeds even if app is not fully ready), the pod might be marked ready but not actually serve traffic. However, the question says readiness probe is TCP on 8080 and app listens on 8080, so it should work.

Another possibility: the pod might have a misconfigured service selector or the pod's labels do not match. But from the options, the most plausible is that the readiness probe is not properly checking application health.

Full explanation →

530

MCQmedium

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

A.An EndpointSlice

B.A regular ClusterIP Service

C.An Ingress resource

D.A headless Service

AnswerB

A ClusterIP Service provides a stable virtual IP and DNS name that load balances to pods.

Why this answer

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

Exam trap

The trap here is that candidates often confuse a headless Service with a regular ClusterIP Service, thinking that because headless Services also provide DNS, they are suitable for stable communication, but they fail to realize that headless Services return a dynamic list of pod IPs rather than a fixed virtual IP, which violates the requirement for an unchanging DNS name.

How to eliminate wrong answers

Option A is wrong because an EndpointSlice is a lower-level resource that tracks the IP addresses of pods matching a Service’s selector; it does not provide a stable DNS name or virtual IP for frontend-to-backend communication. Option C is wrong because an Ingress resource handles external HTTP/HTTPS traffic routing into the cluster, not internal service-to-service DNS-based communication. Option D is wrong because a headless Service (clusterIP: None) does not provide a single stable virtual IP or a round-robin DNS name; it returns the IPs of all matching pods directly, which can change as pods are recreated, breaking the requirement for a fixed DNS name.

Full explanation →

531

MCQhard

You are a platform engineer for a large e-commerce site. The application is deployed on a Kubernetes cluster with 10 worker nodes. Recently, a new deployment 'checkout' was rolled out, and soon after, the cluster experienced network latency and intermittent connectivity issues between services. The 'checkout' pods are configured with a liveness probe that makes an HTTP request to an internal health endpoint. Upon investigation, you find that the kubelet on several nodes is consuming high CPU, and the number of iptables rules has increased significantly. You suspect that the 'checkout' deployment's configuration is causing excessive churn in the network rules. Which aspect of the deployment configuration is most likely the root cause?

A.The liveness probe is configured with a very short periodSeconds (e.g., 1) and a low failureThreshold.

B.The liveness probe uses a TCP socket check instead of an HTTP GET.

C.The deployment sets resource requests and limits that are too low, causing pod throttling.

D.The deployment uses a large number of environment variables, causing slow container startup.

AnswerA

Frequent probes can cause kubelet to update iptables often, especially if the probe goes through a service.

Why this answer

A liveness probe with a very short `periodSeconds` (e.g., 1) and a low `failureThreshold` causes the kubelet to send HTTP requests to the health endpoint at a high frequency. Each probe failure triggers a pod restart, which in turn causes the kubelet to update iptables rules (e.g., for kube-proxy and network policies) to reflect the new pod IP. This rapid churn of pod restarts leads to a significant increase in iptables rules and high CPU consumption on the kubelet, as it must repeatedly reconcile the network state.

Exam trap

The trap here is that candidates may focus on the probe type (HTTP vs. TCP) or resource limits, but the root cause is the probe frequency and failure threshold causing rapid pod restarts and iptables churn, not the probe mechanism itself.

How to eliminate wrong answers

Option B is wrong because a TCP socket check does not inherently cause more iptables churn than an HTTP GET; both probe types trigger restarts on failure, and the frequency of restarts is determined by `periodSeconds` and `failureThreshold`, not the probe protocol. Option C is wrong because low resource requests/limits cause pod throttling or OOM kills, which could lead to restarts, but the question specifically points to excessive iptables rule churn from the deployment configuration, not resource starvation. Option D is wrong because a large number of environment variables slows container startup but does not directly cause iptables rule churn or kubelet CPU spikes; environment variables are set once at pod creation and do not affect network rule updates.

Full explanation →

532

MCQmedium

A company wants to deploy a stateless web application on Kubernetes. The application needs to be accessible externally via a stable IP address and should support SSL termination at the ingress level. Which resource should be used to route external traffic to the application?

A.ClusterIP

B.NodePort

C.Ingress

D.LoadBalancer

AnswerC

Ingress provides external access, SSL termination, and routing rules.

Why this answer

Ingress is the correct resource because it provides external HTTP/HTTPS access to services within a cluster, supports SSL/TLS termination at the ingress controller level, and can expose multiple services under a single stable IP address or hostname. Unlike other service types, Ingress is specifically designed for layer 7 routing and SSL termination, making it ideal for stateless web applications that require a stable external endpoint.

Exam trap

The trap here is that candidates often confuse LoadBalancer with Ingress, thinking LoadBalancer can handle SSL termination natively, but in Kubernetes, LoadBalancer only provides a stable external IP at layer 4 (TCP/UDP) and does not terminate SSL; SSL termination is a layer 7 feature that requires an Ingress controller or a separate reverse proxy.

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 a proxy or port-forward. Option B is wrong because NodePort exposes the service on a static port on each node's IP, but it does not support SSL termination natively, requires managing non-standard ports, and does not provide a stable external IP. Option D is wrong because LoadBalancer provisions an external load balancer with a stable IP, but it does not handle SSL termination at the ingress level; SSL termination would need to be configured separately on the load balancer or within the application, and it typically creates one load balancer per service, which is less efficient for multiple services.

Full explanation →

533

MCQeasy

Which of the following is a valid schedule for a CronJob that runs every day at midnight?

A.0 0 1 * *

B.* * * * *

C.0 * * * *

D.0 0 * * *

AnswerD

This is the correct cron expression for daily at midnight.

Why this answer

Cron schedule format: minute hour day month weekday. '0 0 * * *' means at minute 0 of hour 0 every day.

Full explanation →

534

MCQhard

You need to configure a liveness probe for a container that listens on TCP port 8080. The probe should wait 5 seconds before starting, check every 10 seconds, and timeout after 2 seconds. Which YAML snippet correctly configures this?

A.livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2

B.livenessProbe: exec: command: - echo - ok initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2

C.livenessProbe: tcpSocket: port: 8080 initialDelay: 5 period: 10 timeout: 2

D.livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 2

AnswerA

This correctly implements the requirements using a TCP probe.

Why this answer

Option A is correct because it uses the `tcpSocket` probe type to check TCP port 8080, which is appropriate for a container that listens on TCP. The fields `initialDelaySeconds: 5`, `periodSeconds: 10`, and `timeoutSeconds: 2` match the required timing parameters exactly as specified in the Kubernetes API.

Exam trap

The trap here is that candidates often confuse the probe types (tcpSocket vs. httpGet vs. exec) and may pick an httpGet probe (option D) because it is more common, or use incorrect field names (option C) due to familiarity with other orchestrators like Docker Compose.

How to eliminate wrong answers

Option B is wrong because it uses an `exec` probe with an `echo ok` command, which checks process health via command execution rather than a TCP socket check on port 8080. Option C is wrong because it uses incorrect field names `initialDelay`, `period`, and `timeout`; Kubernetes requires the `Seconds` suffix for these fields (e.g., `initialDelaySeconds`). Option D is wrong because it uses an `httpGet` probe, which performs an HTTP GET request on port 8080, not a TCP socket check; this would fail if the container only listens on TCP without an HTTP server.

Full explanation →

535

Drag & Dropmedium

Sequence the steps to scale a Deployment to 5 replicas and verify.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Check current state, scale, watch Pods, confirm count, and inspect events.

Full explanation →

536

Multi-Selecthard

Which THREE of the following are valid ways to debug a pod that is not responding? (Select three.)

Select 3 answers

A.Run 'kubectl debug -it pod-name --image=busybox --target=container-name' to start an ephemeral debug container

B.Run 'kubectl exec -it pod-name -- /bin/bash' to interact with the container

C.Run 'kubectl logs pod-name --tail=50' to view recent log output

D.Run 'kubectl attach pod-name' to attach to the container's main process

E.Run 'kubectl get pod pod-name -o yaml' to examine the pod's current YAML definition

AnswersA, B, C

Ephemeral containers allow debugging without modifying the original pod.

Why this answer

Multiple methods exist: exec for interactive shell, logs for output, debug for ephemeral containers. Option B is not a valid command; Option D is for configuration files, not runtime debugging.

Full explanation →

537

MCQeasy

Which Dockerfile instruction sets a command that can be overridden when running the container?

A.RUN

B.EXPOSE

C.ENTRYPOINT

D.CMD

AnswerD

CMD specifies the command to run by default; it can be overridden by supplying a command after the image name in 'docker run'.

Why this answer

The CMD instruction provides defaults for executing the container; it can be overridden by command-line arguments. ENTRYPOINT, on the other hand, defines the executable that will always run.

Full explanation →

538

MCQmedium

A developer reports that a pod named 'api-pod' is restarted repeatedly. You run 'kubectl get events --field-selector involvedObject.name=api-pod' and see multiple events with reason 'BackOff' and message 'Back-off restarting failed container'. Which probe failure is MOST likely causing this?

A.Resource quota exceeded

B.Readiness probe failure

C.Startup probe failure

D.Liveness probe failure

AnswerD

Correct. Liveness probe restarts the container when it fails.

Why this answer

BackOff restarting failed container indicates that the container exited and is being restarted by the restart policy. This is commonly caused by a failing liveness probe that kills the container, or the container itself exits. The liveness probe is designed to restart unhealthy containers.

Full explanation →

539

MCQhard

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

A.hostPath

B.persistentVolumeClaim

C.emptyDir

D.Projected volume

AnswerD

Projected volume can mount ConfigMap and updates are reflected if the application monitors the file.

Why this answer

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

Exam trap

The trap here is that candidates often confuse emptyDir with a mechanism that can automatically populate from a ConfigMap, but emptyDir only provides an empty scratch space and does not inject ConfigMap data, while Projected volume is the correct choice for combining multiple sources with live updates.

How to eliminate wrong answers

Option A is wrong because hostPath mounts a file or directory from the host node's filesystem, which does not reflect ConfigMap updates and ties the pod to a specific node, violating the requirement for dynamic updates without restart. Option B is wrong because persistentVolumeClaim is used for persistent storage (e.g., block or filesystem storage) and is not designed to mount ConfigMap data; it cannot reflect ConfigMap updates. Option C is wrong because emptyDir provides a temporary directory that is created when a pod is assigned to a node and is deleted when the pod is removed; it does not automatically populate or update with ConfigMap data, and any ConfigMap content would need to be manually written or copied, which defeats the purpose of live updates.

Full explanation →

540

Multi-Selecteasy

Which TWO are valid fields in a Deployment's rollingUpdate configuration? (Select 2)

Select 2 answers

A.minReadySeconds

B.maxSurge

C.maxUnavailable

D.progressDeadlineSeconds

E.revisionHistoryLimit

AnswersB, C

Controls how many extra pods can be created.

Why this answer

maxSurge and maxUnavailable are the two fields in rollingUpdate.

Full explanation →

541

Multi-Selectmedium

Which THREE of the following are correct statements about Helm?

Select 3 answers

A.Values defined in a 'values.yaml' file can be referenced in templates using '{{ .Values.key }}'.

B.The command 'helm rollback RELEASE REVISION' can undo a release to a previous revision.

C.Helm can be used to manage the lifecycle of a Kubernetes cluster itself.

D.Helm uses a two-way strategic merge patch during upgrades.

E.Helm charts can be stored in a Helm repository and shared.

AnswersA, B, E

Template engine injects values from values.yaml.

Why this answer

Option A is correct: Helm charts can be shared via repositories. Option B is correct: 'helm rollback' restores a previous revision. Option C is correct: values are injected into templates.

Option D is false: Helm does not manage Kubernetes clusters; it deploys resources. Option E is false: Helm 3 uses three-way strategic merge patch, not two-way.

Full explanation →

542

Multi-Selectmedium

Which THREE of the following are valid ways to expose a set of pods as a network service?

Select 3 answers

A.LoadBalancer Service

B.Ingress

C.ClusterIP Service

D.NodePort Service

E.ExternalName Service

AnswersA, C, D

Exposes externally via cloud load balancer.

Why this answer

A LoadBalancer Service is a valid way to expose a set of pods as a network service because it provisions an external load balancer (e.g., from a cloud provider) that distributes traffic to the pods via a NodePort and ClusterIP underneath. This allows external clients to access the service using a single IP address or hostname, making it suitable for production-grade external exposure.

Exam trap

The trap here is that candidates often confuse Ingress as a Service type or think ExternalName can expose pods, when in fact Ingress is a separate resource and ExternalName only maps to an external DNS name without any pod connectivity.

Full explanation →

543

MCQhard

A pod is stuck in the Pending state. You run 'kubectl describe pod pod-name' and see the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 nodes had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.' What is the MOST likely cause?

A.The nodes have disk pressure and the pod lacks tolerations

B.The pod has a resource request that exceeds node capacity

C.The nodes have insufficient CPU

D.The nodes have insufficient memory

AnswerA

The event shows disk-pressure taints on 3 nodes. The pod cannot tolerate them, so it remains Pending.

Why this answer

The disk-pressure taint on 3 nodes indicates those nodes have disk pressure. The control-plane taint on 1 node is normal. The pod cannot be scheduled because nodes are tainted and the pod does not have corresponding tolerations.

The solution is to either free disk space on the nodes or add tolerations.

Full explanation →

544

MCQhard

A container image requires a seccomp profile that is not the default. The cluster supports the RuntimeDefault seccomp profile. Which Pod securityContext field should be configured to use the RuntimeDefault seccomp profile?

A.seccompProfile: type: RuntimeDefault

B.seccomp: type: RuntimeDefault

C.capabilities: add: [SECCOMP]

D.securityContext: seccomp: type: Unconfined

AnswerA

Correct. This sets the seccomp profile to the runtime default.

Why this answer

Option A is correct because the `seccompProfile` field under the Pod's `securityContext` is the proper way to specify a seccomp profile in Kubernetes. Setting `type: RuntimeDefault` tells the container runtime (e.g., containerd or CRI-O) to use the default seccomp profile provided by the runtime, which is a secure baseline that blocks around 44 system calls while allowing common ones like `read`, `write`, and `exit`. This field was introduced in Kubernetes 1.19 (GA in 1.22) and is the standard approach for configuring seccomp at the Pod or container level.

Exam trap

The trap here is that candidates confuse the old alpha annotation `seccomp.security.alpha.kubernetes.io/pod` (deprecated in 1.19) with the current `seccompProfile` field, or they mistakenly think `capabilities` can set the seccomp profile, when in fact capabilities only grant permission to use seccomp syscalls, not apply a profile.

How to eliminate wrong answers

Option B is wrong because `seccomp` is not a valid field in the Pod `securityContext`; the correct field is `seccompProfile`, and the `type` subfield specifies the profile type (e.g., RuntimeDefault, Localhost, Unconfined). Option C is wrong because `capabilities` with `SECCOMP` is a Linux capability that allows a process to install seccomp filters, but it does not configure the Pod to use the RuntimeDefault profile; it grants the ability to manipulate seccomp, which is a different concept. Option D is wrong because `securityContext` does not have a `seccomp` field; the correct structure is `seccompProfile.type`, and `Unconfined` disables seccomp entirely, which is the opposite of using the RuntimeDefault profile.

Full explanation →

545

Multi-Selecteasy

Which TWO of the following are correct about the difference between 'kubectl apply' and 'kubectl create'?

Select 2 answers

A.'kubectl apply' can be used to update existing resources, whereas 'kubectl create' will fail if the resource already exists.

B.'kubectl apply' is declarative, while 'kubectl create' is imperative.

C.'kubectl apply' can only be used to create resources, not update them.

D.'kubectl apply' will delete resources if they are removed from the file.

E.'kubectl create' can only create resources from YAML files, not from stdin.

AnswersA, B

Apply updates; create fails on existing resources.

Why this answer

Option A is correct: apply uses declarative management; create is imperative. Option B is correct: apply can create and update resources; create only creates. Option C is false: create can also create resources from files.

Option D is false: both can create resources. Option E is false: apply does not delete resources by default.

Full explanation →

546

MCQeasy

What is the purpose of a readiness probe in Kubernetes?

A.To control whether the pod receives traffic from Services

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

C.To monitor resource usage of the container

D.To restart the container if it becomes unhealthy

AnswerA

A failing readiness probe removes the pod from Service endpoints.

Why this answer

Option B is correct. Readiness probes determine if a container is ready to serve traffic. If they fail, the pod is removed from Service endpoints.

Option A describes liveness probes. Option C describes startup probes. Option D is incorrect.

Full explanation →

547

MCQeasy

Which command shows the rollout history of a Deployment named 'web'?

A.kubectl rollout status deployment web

B.kubectl get deployment web -o yaml

C.kubectl describe deployment web

D.kubectl rollout history deployment web

AnswerD

Correct. This command displays the revision history.

Why this answer

Option D is correct because `kubectl rollout history deployment web` is the dedicated command to display the revision history of a Deployment, including revision numbers and change-cause annotations. This command directly queries the Deployment's rollout state from the Kubernetes API server, showing each revision's metadata.

Exam trap

The trap here is that candidates confuse `rollout status` (which shows current progress) with `rollout history` (which shows past revisions), or assume `describe` or `get -o yaml` would include historical data when they only show the current state.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout status deployment web` shows the current rollout progress (e.g., waiting for pods to become ready), not the historical list of revisions. Option B is wrong because `kubectl get deployment web -o yaml` outputs the full YAML manifest of the current Deployment spec, not the rollout history. Option C is wrong because `kubectl describe deployment web` provides a summary of the current Deployment state, including events and conditions, but does not list past revisions or rollout history.

Full explanation →

548

MCQeasy

Which kubectl command creates a Secret named 'tls-secret' from a TLS certificate file 'cert.pem' and private key file 'key.pem'?

A.kubectl create secret tls tls-secret --certificate=cert.pem --private-key=key.pem

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

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

D.kubectl create secret docker-registry tls-secret --cert=cert.pem --key=key.pem

AnswerB

This creates a kubernetes.io/tls Secret with the certificate and key.

Why this answer

Option B is correct because the `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and private key pair. The correct flags are `--cert` for the certificate file and `--key` for the private key file, matching the usage shown in option B.

Exam trap

The trap here is that candidates confuse the `--cert` and `--key` flags with similar flags from other tools (like OpenSSL) or assume `--certificate` is the correct flag, leading them to choose option A, or they mistakenly use `generic` instead of `tls` for TLS secrets, as in option C.

How to eliminate wrong answers

Option A is wrong because it uses `--certificate` and `--private-key` flags, which are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because it uses `kubectl create secret generic`, which creates a generic Opaque secret, not a TLS secret; TLS secrets require the `tls` type to properly encode the certificate and key with the correct keys (`tls.crt` and `tls.key`). Option D is wrong because it uses `kubectl create secret docker-registry`, which is for creating a Docker registry authentication secret, not a TLS secret; it expects `--docker-username`, `--docker-password`, etc., not certificate files.

Full explanation →

549

MCQmedium

You create a Service named 'backend' in namespace 'prod'. A pod in namespace 'dev' tries to reach the service using the DNS name 'backend.prod.svc.cluster.local'. The pod cannot resolve the name. What is the most likely cause?

A.CoreDNS is configured to reject cross-namespace queries

B.The 'prod' namespace does not exist

C.The pod is using the short name 'backend' without the namespace suffix

D.The cluster DNS service is not running

AnswerC

Pods can only resolve short service names within the same namespace. To resolve a service in another namespace, the FQDN must be used.

Why this answer

By default, Kubernetes DNS resolves names within the same namespace. To resolve across namespaces, the fully qualified domain name (FQDN) must be used. Option B is correct.

Option A is incorrect because cluster DNS is enabled by default. Option C is incorrect because CoreDNS can resolve cross-namespace requests if the FQDN is used. Option D is incorrect because namespace deletion would remove the service entirely.

Full explanation →

550

MCQmedium

You deploy a pod with resource requests: cpu: 500m, memory: 256Mi and limits: cpu: 1, memory: 512Mi. The container tries to allocate 600Mi of memory. What happens?

A.The container is OOMKilled because it exceeds the memory limit

B.The container runs normally, but memory usage is throttled

C.The container runs normally because requests are the only constraints

D.The container is evicted from the node

AnswerA

Exceeding the memory limit triggers OOM kill.

Why this answer

The correct answer is A because the container's memory allocation of 600Mi exceeds its configured memory limit of 512Mi. Kubernetes enforces memory limits using the cgroup memory controller; when a container attempts to allocate more memory than its limit, the kernel's Out-Of-Memory (OOM) killer terminates the container process. This results in the container being OOMKilled, as recorded in the pod status.

Exam trap

CNCF often tests the misconception that memory, like CPU, can be throttled when limits are exceeded, but memory is a non-compressible resource and exceeding its limit always results in an OOM kill, not throttling.

How to eliminate wrong answers

Option B is wrong because memory is not a compressible resource like CPU; exceeding the memory limit triggers an OOM kill, not throttling. Option C is wrong because memory limits are hard constraints enforced by Kubernetes, not just requests; requests are used for scheduling, while limits are enforced at runtime. Option D is wrong because eviction occurs when a node is under memory pressure and the kubelet reclaims resources by terminating pods, not when a single container exceeds its own limit.

Full explanation →

551

Multi-Selectmedium

Which TWO statements about Init Containers are correct? (Select exactly 2.)

Select 2 answers

A.Init containers run in parallel to reduce startup time

B.Init containers run to completion sequentially before any app containers start

C.Init containers can use a different container image than the app containers

D.If an init container fails, Kubernetes restarts it until it succeeds regardless of restartPolicy

E.Init containers can have liveness and readiness probes

AnswersB, C

They run one after another, each must complete successfully.

Why this answer

Init containers run sequentially and can have different images than the main container. They do not support liveness/readiness probes (only startup probe is allowed, but not by default).

Full explanation →

552

MCQmedium

A pod is running with a SecurityContext that sets 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process is running as user 1000. However, the container needs to access a file on a mounted volume that is owned by user 1000 and group 2000. Which SecurityContext setting should be added to ensure the container can read the file?

A.Set fsGroup: 2000 in the pod-level securityContext

B.Set readOnlyRootFilesystem: true

C.Set runAsGroup: 2000

D.Add capability: CAP_DAC_READ_SEARCH

AnswerA

Setting fsGroup to 2000 ensures that all files in mounted volumes are group-owned by GID 2000, and the container processes have that group as a supplementary group, enabling read access.

Why this answer

The 'fsGroup' field in the pod's SecurityContext changes the group ownership of any files in the mounted volumes to the specified GID, and all container processes are part of the supplementary group. This allows the container to read files with group 2000 if fsGroup is set to 2000. Option A (runAsGroup: 2000) would change the primary group of the process, but the file's group is 2000 and the container runs as user 1000, which might not own the file; fsGroup is the correct approach.

Option C adds capabilities, which are not related to file access groups. Option D sets readOnlyRootFilesystem, which doesn't help with volume access.

Full explanation →

553

MCQeasy

Which command creates a generic Secret with username=admin and password=secret123?

A.kubectl create secret tls mysecret --from-literal=username=admin --from-literal=password=secret123

B.kubectl create secret generic mysecret --from-env-file=username=admin,password=secret123

C.kubectl create secret generic mysecret --from-file=username=admin --from-file=password=secret123

D.kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=secret123

AnswerD

Correct syntax for creating a secret from literals.

Why this answer

Option D is correct because `kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line, creating a generic (opaque) Secret with the literal values `username=admin` and `password=secret123`. This is the standard way to create a generic Secret from literal data.

Exam trap

CNCF often tests the distinction between `--from-literal`, `--from-file`, and `--from-env-file`, and candidates commonly confuse `--from-file` (which expects a file path) with `--from-literal` (which expects a key=value pair).

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS Secret, which expects a `--cert` and `--key` file, not literal key-value pairs, and is used for TLS certificates, not generic credentials. Option B is wrong because `--from-env-file` expects a file path (e.g., a `.env` file), not inline key-value pairs; the syntax `--from-env-file=username=admin,password=secret123` is invalid and would cause an error. Option C is wrong because `--from-file` expects a file path (e.g., `--from-file=username=./username.txt`), not literal key-value pairs; using `--from-file=username=admin` would try to read a file named `admin` in the current directory, not set the value to `admin`.

Full explanation →

554

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'app.properties'?

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

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

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

D.kubectl create configmap app-config --file=app.properties

AnswerA

Correct. The --from-file flag creates a ConfigMap from a file.

Why this answer

Option A is correct because `kubectl create configmap app-config --from-file=app.properties` reads the file `app.properties` and creates a ConfigMap with a single key-value pair where the key is the filename (without extension) and the value is the entire file content. This is the standard way to create a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is confusing `--from-file` (which stores the entire file content as a single value) with `--from-env-file` (which parses the file as key-value pairs for environment variables), leading candidates to pick option C when they need to import a properties file as a single blob.

How to eliminate wrong answers

Option B is wrong because `--from-literal` expects a key=value pair directly on the command line, not a filename; using `--from-literal=app.properties` would create a ConfigMap with the literal string 'app.properties' as both the key and value, not the file's content. Option C is wrong because `--from-env-file` is used to import a file containing multiple key=value lines (one per line) as environment variables, not to store the entire file content as a single value. Option D is wrong because `--file` is not a valid flag for the `kubectl create configmap` command; the correct flag is `--from-file`.

Full explanation →

555

MCQmedium

You are tasked with deploying a stateless web application on a Kubernetes cluster. The application is containerized and listens on port 8080. You have created a Deployment named 'webapp' with 3 replicas, and a ClusterIP Service named 'webapp-svc' exposing port 80 targeting the application's port 8080. During testing, you notice that some requests to the service return errors while others succeed. You have verified that all Pods are running and ready. The application logs show no errors. What is the most likely cause of the intermittent failures?

A.The ClusterIP Service type does not support load balancing.

B.The Service is not configured with enough endpoints.

C.The Service's targetPort is set incorrectly, causing traffic to be misrouted.

D.The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.

AnswerD

Correct; without a readiness probe, the Service may send traffic to Pods that are not ready, leading to intermittent failures.

Why this answer

The intermittent failures are most likely caused by the absence of a readiness probe in the Deployment. Without a readiness probe, the Service's EndpointSlice controller considers all Pods with a matching label selector as ready endpoints, even if the application inside the container has not finished initializing or is temporarily unable to serve traffic. This results in the ClusterIP Service load-balancing requests to Pods that are not actually ready, causing some requests to fail while others succeed.

Exam trap

CNCF often tests the distinction between 'Pod is Running' (container process started) and 'Pod is Ready' (application is healthy and can serve traffic), trapping candidates who assume that a Running Pod is automatically ready to receive Service traffic.

How to eliminate wrong answers

Option A is wrong because ClusterIP Services do provide internal load balancing via kube-proxy using iptables or IPVS rules, distributing traffic across ready endpoints. Option B is wrong because the Service is configured with a label selector matching the Deployment's Pods, and with 3 replicas all running and ready (as verified), there are exactly 3 endpoints — enough for load balancing. Option C is wrong because the targetPort is set to 8080, which matches the container's listening port, so traffic is correctly routed to the application.

Full explanation →

556

MCQeasy

Which of the following is the correct way to create a simple Pod named 'nginx' running the nginx:1.25 image using kubectl?

A.kubectl create nginx --image=nginx:1.25

B.kubectl create pod nginx --image=nginx:1.25

C.kubectl apply nginx --image=nginx:1.25

D.kubectl run nginx --image=nginx:1.25

AnswerD

'kubectl run' creates a pod with the specified image. This is the correct command.

Why this answer

Option C is correct. The 'kubectl run' command with the '--image' flag creates a pod. Option A is incorrect because 'kubectl create pod' is not a valid command; you would use 'kubectl create deployment' or 'kubectl run'.

Option B is incorrect because 'kubectl apply' expects a YAML file, not an image argument directly. Option D is incorrect because 'kubectl create' expects a resource type (e.g., 'deployment'), not 'pod' directly.

Full explanation →

557

Multi-Selectmedium

Which TWO fields are required in a CronJob manifest? (Select 2)

Select 2 answers

A.startingDeadlineSeconds

B.successfulJobsHistoryLimit

C.schedule

D.concurrencyPolicy

E.jobTemplate

AnswersC, E

The cron schedule is mandatory.

Why this answer

Options A and D are required. A CronJob must have 'schedule' (A) and 'jobTemplate' (D). Option B (concurrencyPolicy) is optional and defaults to Allow.

Option C (successfulJobsHistoryLimit) is optional. Option E (startingDeadlineSeconds) is optional.

Full explanation →

558

MCQeasy

What is the purpose of the '.dockerignore' file?

A.To specify which files to include in the image

B.To ignore files during docker push

C.To exclude files from the build context

D.To list environment variables to ignore

AnswerC

Files listed in .dockerignore are not sent to the Docker daemon.

Why this answer

.dockerignore prevents unnecessary files from being sent to the Docker daemon as part of the build context.

Full explanation →

559

MCQmedium

You have a multi-stage Dockerfile for a Go application. The first stage compiles the binary, and the second stage uses a scratch image. Which of the following is the correct way to copy the binary from the first stage into the second stage?

A.ADD --from=builder /app/bin /app/

B.COPY /app/bin /app/

C.COPY --from=builder /app/bin /app/

D.COPY --from=0 /app/bin /app/

AnswerC

Correct: 'COPY --from=builder' copies files from the stage named 'builder'.

Why this answer

Option B is correct. The COPY --from=builder syntax copies files from the previous stage named 'builder'. Option A copies from the host, not the builder stage.

Option C copies from an image, but the image name is missing and it's not the standard way. Option D uses ADD which can be used but is recommended for tarballs, not for copying from builder stages.

Full explanation →

560

MCQmedium

During a rolling update, you want to ensure that a maximum of 2 extra pods are created above the desired replicas. Which field should you set in the Deployment spec?

A.spec.template.spec.containers.resources

B.spec.strategy.rollingUpdate.maxSurge

C.spec.replicas

D.spec.strategy.rollingUpdate.maxUnavailable

AnswerB

maxSurge defines the maximum number of pods that can be created above the desired replicas during a rolling update.

Why this answer

The 'maxSurge' field controls how many extra pods can be created during a rolling update. Setting it to 2 allows up to 2 extra pods. Option D is correct.

Full explanation →

561

Multi-Selectmedium

Which TWO of the following are valid types of Secrets in Kubernetes?

Select 2 answers

A.Opaque

B.kubernetes.io/ssh-auth

C.configmap

D.dockerconfigjson

E.kubernetes.io/tls

AnswersA, E

Opaque secrets store arbitrary key-value pairs.

Why this answer

Option A is correct because Opaque is the default Secret type in Kubernetes, used for storing arbitrary key-value pairs such as passwords or tokens. It is defined as `Opaque` in the Secret's `type` field and is the most commonly used Secret type for general-purpose sensitive data.

Exam trap

CNCF often tests the exact naming of built-in Secret types, and the trap here is that candidates may confuse `dockerconfigjson` (missing the `kubernetes.io/` prefix) with the valid `kubernetes.io/dockerconfigjson`, or assume `configmap` is a Secret type when it is a separate resource.

Full explanation →

562

MCQmedium

A Pod specification includes: securityContext: { runAsNonRoot: true }. The container image runs as root by default. What will happen when the Pod is created?

A.The Pod will start and immediately be OOMKilled

B.The Pod will run but with a warning

C.The Pod will not start; the kubelet will reject it because the container tries to run as root

D.The Pod will run successfully because K8s overrides the user to non-root

AnswerC

The Pod will be rejected during admission or at runtime, and remain in a pending/error state.

Why this answer

When a Pod specifies `runAsNonRoot: true` in its `securityContext`, the kubelet verifies that the container's user ID is non-zero (non-root) before starting the container. If the container image runs as root by default (UID 0), the kubelet will reject the Pod, and it will remain in a `ContainerCreating` or `CrashLoopBackOff` state with an error like 'container has runAsNonRoot and image will run as root'. This is a security enforcement mechanism that prevents privileged execution.

Exam trap

The trap here is that candidates assume Kubernetes will automatically adjust the container user to non-root when `runAsNonRoot` is set, but in reality, Kubernetes only validates the existing user and rejects the Pod if it's root—you must explicitly set `runAsUser` to a non-zero value if the image runs as root.

How to eliminate wrong answers

Option A is wrong because OOMKilled (Out Of Memory Killed) occurs when a container exceeds its memory limit, not due to security context violations; the Pod is rejected before any execution. Option B is wrong because Kubernetes does not issue warnings for security context violations—it enforces them strictly by failing the Pod creation, and the event logs will show an error, not a warning. Option D is wrong because Kubernetes does not automatically override the container's user to non-root; the `runAsNonRoot` flag only validates the user, and if the image runs as root, the Pod is rejected unless you explicitly set `runAsUser` to a non-zero value.

Full explanation →

563

Multi-Selectmedium

Which TWO of the following are valid types of probes in Kubernetes? (Select 2)

Select 2 answers

A.Liveness probe

B.Survival probe

C.Readiness probe

D.Health probe

E.Startup probe

AnswersA, C

One of the three probe types.

Why this answer

Liveness, readiness, and startup are the three probe types. Option D is not a probe type. Option E is not a standard probe type.

Full explanation →

564

Multi-Selectmedium

Which THREE items are required for Ingress to work correctly in a Kubernetes cluster?

Select 3 answers

A.At least one rule specifying either host or path

B.An Ingress controller running in the cluster

C.A TLS secret for HTTPS termination

D.A LoadBalancer service for the backend

E.A default backend service

AnswersA, B, C

Rules define how to route traffic.

Why this answer

An Ingress resource needs an Ingress controller to process it. Rules define routing. TLS configuration enables HTTPS.

IngressClass is optional but recommended. Backend service must be of type ClusterIP.

Full explanation →

565

Multi-Selecthard

Which THREE of the following are valid fields in the '.spec' of a Job manifest?

Select 3 answers

A.replicas

B.parallelism

C.strategy

D.completions

E.backoffLimit

AnswersB, D, E

Specifies the maximum number of pods running concurrently.

Why this answer

backoffLimit, parallelism, and completions are all valid Job spec fields.

Full explanation →

566

Drag & Dropmedium

Arrange the steps to create a multi-container Pod with a shared volume.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Define Pod with containers, add shared emptyDir volume, mount in each container, apply, then test.

Full explanation →

567

Multi-Selecthard

Which THREE are valid ways to create a ConfigMap?

Select 3 answers

A.kubectl create configmap my-config --from-literal=key=value

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

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

D.kubectl create configmap my-config --from-file=key=file

E.kubectl apply configmap my-config --from-literal=key=value

AnswersA, B, C

Valid.

Why this answer

Option A is correct because `kubectl create configmap` with `--from-literal` directly creates a ConfigMap with a key-value pair from the command line, which is a standard and valid method. This approach is ideal for simple, single-key configurations without needing external files.

Exam trap

The trap here is that candidates may confuse `kubectl create configmap` with `kubectl apply` or misremember the syntax for `--from-file` with a custom key, leading them to select invalid options like D or E.

Full explanation →

568

MCQeasy

Which command creates a TLS secret from an existing certificate and key file?

A.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem

B.kubectl create secret tls my-tls --from-file=cert.pem --from-file=key.pem

C.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

D.kubectl create secret docker-registry my-tls --docker-server=... --docker-username=... --docker-password=...

AnswerA

Correct.

Why this answer

Option A is correct because the `kubectl create secret tls` command is specifically designed to create a TLS secret from an existing certificate and key file. The `--cert` and `--key` flags directly specify the paths to the PEM-encoded certificate and private key, which Kubernetes then stores as a `kubernetes.io/tls` secret type, automatically base64-encoding the data for secure storage in etcd.

Exam trap

The trap here is that candidates confuse the `--from-file` flag (used for generic secrets) with the `--cert` and `--key` flags (required for TLS secrets), leading them to choose option B or C, which would create a secret of the wrong type or with incorrect key mappings.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret tls` does not support `--from-file` flags; those flags are used with `kubectl create secret generic` or `kubectl create secret docker-registry`, and using them with `tls` would result in a syntax error or create a generic secret instead of a TLS secret. Option C is wrong because `kubectl create secret generic` creates a generic secret (type `Opaque`), not a TLS secret (type `kubernetes.io/tls`), and the `--from-file` flags would store the files as arbitrary keys rather than the required `tls.crt` and `tls.key` entries. Option D is wrong because `kubectl create secret docker-registry` creates a Docker registry authentication secret (type `kubernetes.io/dockercfg`), which is used for pulling images from private registries, not for storing TLS certificates and keys.

Full explanation →

569

MCQmedium

You are writing a Deployment manifest for a container that takes up to 60 seconds to become ready. You want to ensure the liveness probe does not interfere during this startup period. What should you configure?

A.Set liveness probe failureThreshold to a high number

B.Set readiness probe initialDelaySeconds to 60

C.Set liveness probe initialDelaySeconds to 60

D.Configure a startup probe with a sufficient failureThreshold and period

AnswerD

Correct. Startup probe delays liveness and readiness probes until the container is fully started.

Why this answer

A startup probe is designed for slow-starting containers. It runs at startup and only after it succeeds does the liveness probe take over.

Full explanation →

570

MCQeasy

Which kubectl command shows the rollout history of a Deployment named 'app'?

A.kubectl rollout status deployment app

B.kubectl describe deployment app

C.kubectl rollout history deployment app

D.kubectl get events --field-selector involvedObject.kind=Deployment

AnswerC

This is the correct syntax to view rollout history.

Why this answer

kubectl rollout history deployment/app shows the revision history of the Deployment.

Full explanation →

571

Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext (pod-level securityContext)? (Select 3)

Select 3 answers

A.runAsUser

B.fsGroup

C.readOnlyRootFilesystem

D.capabilities

E.seccompProfile

AnswersA, B, E

Valid at pod level; sets the user for all containers.

Why this answer

Option A is correct because `runAsUser` is a valid field in a PodSecurityContext that sets the user ID (UID) for all containers in the pod, overriding any container-level `securityContext.runAsUser`. This is defined in the Kubernetes API under `PodSecurityContext` and is commonly used to enforce non-root execution.

Exam trap

CNCF often tests the distinction between pod-level and container-level securityContext fields, and the trap here is that candidates confuse `readOnlyRootFilesystem` and `capabilities` as pod-level fields when they are actually only valid at the container level.

Full explanation →

572

Multi-Selectmedium

Which THREE of the following are valid reasons to use a HorizontalPodAutoscaler (HPA) with a Deployment?

Select 3 answers

A.To set a fixed 'targetCPUUtilizationPercentage' that scales down the deployment when exceeded.

B.To scale replicas based on the number of incoming HTTP requests per second.

C.To scale replicas based on custom metrics exposed by the application.

D.To ensure that each pod has at least a certain amount of CPU resources reserved.

E.To automatically scale the number of replicas based on average CPU utilization across pods.

AnswersB, C, E

Can be implemented with custom metrics (e.g., Prometheus).

Why this answer

Option A is correct: HPA can scale based on CPU/memory metrics. Option B is correct: custom metrics can be used. Option C is correct: HPA can scale based on incoming request rate via custom metrics.

Option D is false: HPA does not enforce resource requests; it scales based on metrics. Option E is false: HPA does not use 'targetCPUUtilizationPercentage' for scaling; that's an older field replaced by metrics.

Full explanation →

573

MCQmedium

A LimitRange in namespace 'limits' sets default memory request to 256Mi and default memory limit to 512Mi. A pod is created without specifying any resources. What are the pod's effective memory request and limit?

A.request: 512Mi, limit: 256Mi

B.request: 256Mi, limit: 512Mi

C.No request or limit; the pod will be scheduled with best-effort QoS

D.request: 0, limit: unlimited

AnswerB

The LimitRange default values are applied to the pod because no resources were specified.

Why this answer

When a LimitRange exists in a namespace, it automatically applies default resource requests and limits to any pod that does not specify them. In this case, the LimitRange sets the default memory request to 256Mi and the default memory limit to 512Mi, so the pod inherits those values. This ensures the pod has a guaranteed QoS class (Guaranteed) because request equals limit, but only if both are set; here they differ, so the pod will be Burstable.

Exam trap

The trap here is that candidates often forget that a LimitRange applies defaults to pods that omit resource specifications, leading them to incorrectly assume the pod will have no limits or be Best-Effort, when in fact the LimitRange enforces both request and limit.

How to eliminate wrong answers

Option A is wrong because it reverses the values: the default request is 256Mi, not 512Mi, and the default limit is 512Mi, not 256Mi. Option C is wrong because a LimitRange in the namespace overrides the absence of resource specifications; the pod will have both request and limit set, resulting in Burstable QoS, not Best-Effort. Option D is wrong because a LimitRange does not leave resources unlimited; it enforces defaults, so the pod will have a request of 256Mi and a limit of 512Mi, not 0 or unlimited.

Full explanation →

574

MCQmedium

What is the correct schedule expression for a CronJob that runs every 5 minutes?

A.*/5 * * * *

B.* * * * *

C.0 */5 * * *

D.5 * * * *

AnswerA

Standard cron syntax for every 5 minutes.

Why this answer

Option B is correct: '*/5 * * * *' runs every 5 minutes. Option A runs every minute. Option C runs at minute 5 every hour.

Option D runs every 5 hours.

Full explanation →

575

Multi-Selecthard

Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)

Select 2 answers

A.Both commands support the --dry-run=client flag.

B.Both commands require a full YAML manifest file.

C.kubectl apply can update existing resources; kubectl create cannot.

D.kubectl create is the recommended way to manage production resources.

E.Both commands can only be used to create resources, not update.

.kubectl apply stores the last applied configuration in an annotation.

AnswersC

apply is for create/update; create only creates and fails if exists.

Why this answer

kubectl apply manages resources declaratively using last-applied-configuration. kubectl create is imperative and will error if resource exists.

Full explanation →

576

MCQeasy

When performing a rolling update of a Deployment with 'maxSurge: 1' and 'maxUnavailable: 0', how many additional pods can be created above the desired replicas during the update?

A.1

B.0

C.Unlimited

D.100%

AnswerA

maxSurge=1 allows one additional pod above the desired replicas.

Why this answer

maxSurge defines the maximum number of pods that can be created above the desired replicas. With maxSurge=1, exactly one extra pod can exist during the update.

Full explanation →

577

MCQmedium

You want to use Kustomize to apply a patch to a Deployment in the 'overlays/production' directory. Which command should you run from the kustomization directory?

A.kubectl create -k overlays/production/

B.kubectl apply -k overlays/production/

C.kustomize build overlays/production/ | kubectl apply -f -

D.kubectl apply -f overlays/production/

AnswerB

Correct command to apply a kustomization.

Why this answer

kubectl apply -k applies the kustomization directory. Option C is correct.

Full explanation →

578

MCQmedium

You have a Helm chart for an application. You want to upgrade the release but only if the upgrade does not introduce breaking changes. Which command should you use?

A.helm install --dry-run my-release ./mychart

B.helm upgrade --dry-run my-release ./mychart

C.helm rollback my-release 0

D.helm diff upgrade my-release ./mychart

AnswerB

--dry-run simulates the upgrade and shows the rendered templates without applying them.

Why this answer

Helm does not have a dry-run for upgrades that guarantees no breaking changes, but 'helm upgrade --dry-run' simulates the upgrade and shows changes without applying them.

Full explanation →

579

MCQmedium

You need to configure a liveness probe for a container that starts a web server on port 8080. The probe should check the '/healthz' endpoint. Which YAML snippet correctly defines this probe?

A.livenessProbe:\n exec:\n command: ["curl", "http://localhost:8080/healthz"]

B.livenessProbe:\n httpGet:\n port: 8080

C.livenessProbe:\n httpGet:\n path: /healthz\n port: 8080

D.livenessProbe:\n tcpSocket:\n port: 8080

AnswerC

This is the correct definition for an HTTP GET liveness probe.

Why this answer

A liveness probe using httpGet checks the specified path and port. The correct syntax includes the path and port fields.

Full explanation →

580

MCQhard

A pod with an init container and a main container has 'restartPolicy: Always'. The init container exits with code 0. What happens next?

A.The pod enters CrashLoopBackOff because the init container should not exit

B.The main container starts; if it fails, it will be restarted

C.The pod is considered complete and enters Succeeded phase

D.The init container restarts and runs again

AnswerB

Init container completed; main container starts and is managed by the restart policy.

Why this answer

Init containers run to completion and are not restarted. The main container starts and runs. If the main container exits, it will be restarted due to restartPolicy Always.

Full explanation →

581

Multi-Selecthard

Which THREE of the following are true about ServiceAccount token automounting? (Choose three.)

Select 3 answers

A.The token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token

B.Automounting can be disabled at the ServiceAccount level by setting automountServiceAccountToken: false.

C.Setting automountServiceAccountToken: false in a Pod spec prevents only that Pod from automounting.

D.The token is automatically refreshed by the kubelet.

E.By default, Kubernetes automounts the default ServiceAccount token into every Pod.

AnswersB, C, E

Correct.

Why this answer

Option B is correct because the `automountServiceAccountToken` field can be set to `false` in the ServiceAccount manifest to prevent the automatic mounting of the token into any Pod that uses that ServiceAccount. This is a declarative way to disable token automounting at the account level, overriding the default behavior where the token is mounted into every Pod.

Exam trap

CNCF often tests the misconception that the token is automatically refreshed by the kubelet, when in fact token rotation is managed by the TokenRequest API and the kube-controller-manager, not the kubelet, and static tokens are not refreshed at all.

Full explanation →

582

MCQeasy

A developer wants to access a specific pod's port 8080 from their local machine using a temporary connection. Which command should they use?

A.kubectl exec -it pod-name -- sh

B.kubectl port-forward pod/pod-name 8080:8080

C.kubectl proxy

D.kubectl expose pod pod-name --port=8080

AnswerB

This command forwards local port 8080 to pod's port 8080.

Why this answer

kubectl port-forward creates a tunnel from a local port to a pod's port.

Full explanation →

583

MCQeasy

Which of the following is the correct apiVersion for a Kubernetes Job in v1.29?

A.batch/v1

B.apps/v1

C.v1

D.batch/v1beta1

AnswerA

batch/v1 is the stable apiVersion for Jobs since Kubernetes 1.21.

Why this answer

In Kubernetes v1.29, the correct apiVersion for a Job is `batch/v1`. The `batch/v1` API version has been stable since Kubernetes 1.21, and Jobs are part of the batch API group. Using `batch/v1` ensures compatibility with the current stable release and provides access to all Job features, including parallelism, completions, and backoff limits.

Exam trap

The trap here is that candidates may confuse the `batch/v1` apiVersion with the older `batch/v1beta1` (which is no longer valid) or incorrectly assume Jobs are part of the core `v1` or `apps/v1` API groups, leading to a wrong answer.

How to eliminate wrong answers

Option B (`apps/v1`) is wrong because `apps/v1` is used for workloads like Deployments, StatefulSets, DaemonSets, and ReplicaSets, not for Jobs. Option C (`v1`) is wrong because `v1` is the core API group (e.g., Pods, Services, ConfigMaps), and Jobs belong to the `batch` API group, not the core group. Option D (`batch/v1beta1`) is wrong because the `batch/v1beta1` version was deprecated in Kubernetes 1.21 and removed in 1.25; using it in v1.29 would result in an API error.

Full explanation →

584

Multi-Selecthard

Which THREE of the following are valid fields in a SecurityContext at the container level? (Select three.)

Select 3 answers

A.fsGroup

B.runAsUser

C.readOnlyRootFilesystem

D.capabilities

E.allowPrivilegeEscalation

AnswersC, D, E

readOnlyRootFilesystem is valid at container level.

Why this answer

Option C is correct because `readOnlyRootFilesystem` is a valid field in a container-level SecurityContext that, when set to `true`, mounts the container's root filesystem as read-only, preventing writes to the container's filesystem and enhancing security by limiting the impact of potential exploits.

Exam trap

CNCF often tests the distinction between Pod-level and container-level SecurityContext fields, and the trap here is that `fsGroup` is a Pod-level field, not a container-level one, while `runAsUser` is valid at both levels but is not among the three correct answers, leading candidates to incorrectly select it.

Full explanation →

585

Multi-Selectmedium

Which TWO of the following are valid ways to expose a container port in a pod spec?

Select 2 answers

A.spec.containers[].ports[].hostPort

B.spec.containers[].hostPort

C.spec.containers[].containerPort

D.EXPOSE 8080 in Dockerfile

E.spec.containers[].ports[].containerPort

AnswersA, E

hostPort maps the container port to a port on the host node.

Why this answer

Option A and E are correct. The 'containerPort' field under 'ports' defines which container ports to expose. 'hostPort' is also valid but less common. Option B is not a valid field (hostPort is a subfield of ports).

Option C is not valid (ports is a list). Option D is a Dockerfile instruction, not a pod spec field.

Full explanation →

586

MCQmedium

A NetworkPolicy with the following spec is applied: spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend What does this policy do?

A.Allows all outgoing traffic from pods labeled 'role: frontend'

B.Blocks all incoming traffic to pods labeled 'role: frontend'

C.Allows incoming traffic from pods labeled 'role: frontend' to all pods

D.Has no effect because policyTypes is missing Egress

AnswerC

The policy selects all pods and allows ingress from matching pods.

Why this answer

An empty podSelector {} selects all pods in the namespace. Since policyTypes includes Ingress only, and the ingress rule allows traffic from pods with label 'role: frontend', all other inbound traffic is denied by default because NetworkPolicy isolates pods when it selects them.

Full explanation →

587

Multi-Selectmedium

Which TWO statements about Ingress are correct?

Select 2 answers

A.An Ingress resource without an IngressClass will not work

B.Only one Ingress resource can exist per namespace

C.Ingress can handle non-HTTP protocols like TCP

D.Ingress can route traffic based on the requested hostname

E.TLS termination can be configured in the Ingress spec

AnswersD, E

Host-based routing is a common feature.

Why this answer

Ingress can route based on host and path, and can terminate TLS. Ingress does not support TCP/UDP directly; it's for HTTP/HTTPS. IngressClass is used to select the Ingress controller.

Multiple Ingress resources can coexist.

Full explanation →

588

MCQhard

You create a Secret with 'kubectl create secret generic db-secret --from-literal=password=myPass'. Later, you mount it as a volume in a pod. When you exec into the container and cat the file, what will you see?

A.password=myPass

B.bXlQYXNz

C.myPass

D.An error because secrets cannot be mounted as volumes

AnswerC

Kubernetes decodes the Secret data when mounting as volume.

Why this answer

Option C is correct because when you mount a Secret as a volume, Kubernetes automatically decodes the base64-encoded data and presents the file contents as the original plaintext value. In this case, the Secret stores the literal key-value pair `password=myPass`, and when mounted, the file named `password` contains the decoded value `myPass`.

Exam trap

The trap here is that candidates often confuse the base64-encoded representation stored in the Secret manifest with the decoded content presented when mounted as a volume, leading them to pick Option B.

How to eliminate wrong answers

Option A is wrong because the file content is not the raw `--from-literal` string `password=myPass`; Kubernetes separates the key from the value, so the file name is the key (`password`) and the file content is the value (`myPass`). Option B is wrong because `bXlQYXNz` is the base64 encoding of `myPass`, but when mounted as a volume, Kubernetes automatically decodes the data, so the file contains the plaintext `myPass`, not the encoded string. Option D is wrong because Secrets can absolutely be mounted as volumes; this is a standard and common method for exposing secret data to pods.

Full explanation →

589

MCQhard

Given the following partial pod spec: ```yaml securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 ``` Which combination correctly describes the resulting permissions on a mounted volume?

A.Volume owned by user 2000, group 1000; container runs with user 2000 and group 1000

B.Volume owned by user 3000, group 2000; container runs with user 1000 and group 3000

C.Volume owned by user 1000, group 2000; container runs with user 1000 and group 3000

D.Volume owned by user 1000, group 3000; container runs with user 1000 and group 2000

AnswerC

runAsUser sets the container user to 1000; runAsGroup sets the primary group to 3000; fsGroup sets the volume's group ownership to 2000.

Why this answer

Option C is correct because `runAsUser: 1000` sets the container's primary user ID to 1000, `runAsGroup: 3000` sets the primary group ID to 3000, and `fsGroup: 2000` changes the group ownership of any mounted volume to group 2000, while also granting the container's processes supplemental group access to group 2000. The volume's user ownership remains the default (often root or the image's user) unless explicitly changed, but the key point is that the volume is group-owned by 2000 and the container runs with UID 1000 and GID 3000.

Exam trap

The trap here is confusing `runAsGroup` (which sets the container's primary GID) with `fsGroup` (which sets the volume's group ownership and adds a supplemental group), leading candidates to incorrectly assign the volume's group to the container's primary group or vice versa.

How to eliminate wrong answers

Option A is wrong because it incorrectly states the volume is owned by user 2000 and group 1000, but `fsGroup` only affects group ownership, not user ownership, and `runAsUser` sets the container's UID to 1000, not 2000. Option B is wrong because it claims the volume is owned by user 3000 and group 2000, but `runAsUser: 1000` sets the container's UID to 1000, not 3000, and `fsGroup: 2000` sets the volume's group to 2000, not the user. Option D is wrong because it states the volume is owned by user 1000 and group 3000, but `fsGroup: 2000` sets the volume's group to 2000, not 3000, and the container's primary group is 3000, not 2000.

Full explanation →

590

Multi-Selecthard

A team wants to deploy a multi-container Pod with a sidecar pattern. Which THREE statements are true about sidecar containers? (Select exactly 3.)

Select 3 answers

A.Sidecar containers are always started before the main container

B.Sidecar containers are used for tasks like log collection, service mesh proxies, or data synchronization

C.Sidecar containers can be updated independently without restarting the main container

D.Sidecar containers run in the same Pod as the main container

E.Sidecar containers share the same network namespace as the main container

AnswersB, D, E

These are common sidecar use cases.

Why this answer

Sidecar containers share the same Pod lifecycle and network namespace, and are typically used for auxiliary tasks like logging, proxying, or sync.

Full explanation →

591

MCQmedium

You need to see the YAML definition of a running pod named 'app' including the current status. Which command should you use?

A.kubectl edit pod app

B.kubectl get pod app -o yaml

C.kubectl get pod app -o yaml --export

D.kubectl get pod app -o json

AnswerB

This outputs the complete YAML definition including status.

Why this answer

Option B is correct because `kubectl get pod app -o yaml` retrieves the current live state of the pod from the Kubernetes API server and outputs it in YAML format, including the `status` field with the latest conditions, container states, and other runtime information. This command directly queries the API without modifying the object, making it the standard way to view the full definition and status of a running pod.

Exam trap

The trap here is that candidates may confuse `kubectl get pod -o yaml` with `kubectl describe pod`, which provides a human-readable summary but not the raw YAML definition, or they may mistakenly choose `--export` thinking it cleans up the output, not realizing it removes the very status information the question requires.

How to eliminate wrong answers

Option A is wrong because `kubectl edit pod app` opens the pod's specification in an editor for modification; while it shows the current state, its primary purpose is editing, not just viewing, and it may inadvertently change the object if saved. Option C is wrong because `--export` is a deprecated flag that strips cluster-specific fields like `status`, `nodeName`, and `uid`, which contradicts the requirement to include the current status. Option D is wrong because `-o json` outputs the pod definition in JSON format, not YAML, so it does not satisfy the explicit request for YAML output.

Full explanation →

592

MCQeasy

Which Dockerfile instruction is used to specify the base image for a container image?

A.COPY

B.FROM

C.CMD

D.RUN

AnswerB

FROM specifies the base image for the build.

Why this answer

The FROM instruction initializes a new build stage and sets the base image for subsequent instructions.

Full explanation →

593

MCQeasy

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

A.A second Service of type NodePort

B.A NetworkPolicy

C.An Ingress resource

D.A ConfigMap

AnswerC

An Ingress provides external HTTP/HTTPS access and can be configured with a stable IP.

Why this answer

A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

Exam trap

CNCF often tests the misconception that a ClusterIP Service alone can be accessed externally, or that a NodePort Service provides a stable IP, when in fact NodePort exposes on ephemeral node IPs and ports, while Ingress provides a stable external endpoint with path-based routing.

How to eliminate wrong answers

Option A is wrong because creating a second NodePort Service would expose the application on a high port on each node, but it does not provide a stable IP address; the node IPs may change, and clients would need to know the specific node and port. Option B is wrong because a NetworkPolicy controls ingress/egress traffic between pods within the cluster, not external access; it cannot expose the application to external clients. Option D is wrong because a ConfigMap is used to store configuration data (e.g., environment variables) for pods, not to expose services externally.

Full explanation →

594

MCQeasy

You have a ConfigMap created from an env file. Which command creates the ConfigMap from the file 'app.env' containing key=value pairs?

A.kubectl create configmap app-config --from-file=app.env

B.kubectl create configmap app-config --env-file=app.env

C.kubectl create configmap app-config --from-literal=app.env

D.kubectl create configmap app-config --from-env-file=app.env

AnswerD

--from-env-file correctly reads env file and creates a ConfigMap with each line as key=value.

Why this answer

Option D is correct because `--from-env-file` is the exact flag used to create a ConfigMap from a file containing key=value pairs in env-file format (e.g., `app.env`). This flag parses each line as a key-value pair and stores them as individual data entries in the ConfigMap, unlike `--from-file` which stores the entire file content under a single key.

Exam trap

CNCF often tests the subtle difference between `--from-file` and `--from-env-file`, where candidates mistakenly choose `--from-file` because they think it handles env files generically, but it does not parse key-value pairs.

How to eliminate wrong answers

Option A is wrong because `--from-file=app.env` creates a ConfigMap where the entire file content is stored as a single entry under the key `app.env`, not as separate key-value pairs. Option B is wrong because `--env-file` is not a valid flag for `kubectl create configmap`; it is used with `kubectl run` to inject environment variables from a file into a pod. Option C is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `key=value`), not to reference a file, and passing `app.env` as a literal would treat it as a literal string, not a file path.

Full explanation →

595

MCQmedium

You need to run a command inside a running pod's container. The container has a shell available. Which command allows you to execute 'ls -la /data' inside the container?

A.kubectl exec pod-name

B.kubectl run pod-name -- ls -la /data

C.kubectl exec pod-name -- ls -la /data

D.kubectl attach pod-name -c container-name

AnswerC

This runs the command 'ls -la /data' inside the pod's first container.

Why this answer

The `kubectl exec` command is designed to execute arbitrary commands inside a running container. The `--` separator tells kubectl that everything after it is the command to run inside the container, not a kubectl flag. Option C correctly uses `kubectl exec pod-name -- ls -la /data` to run `ls -la /data` inside the specified pod's primary container.

Exam trap

The trap here is confusing `kubectl exec` (which runs a command inside an existing container) with `kubectl run` (which creates a new pod), leading candidates to pick Option B, which would create a new pod instead of executing in the running one.

How to eliminate wrong answers

Option A is wrong because `kubectl exec pod-name` without a command after `--` will open an interactive shell (if available) or fail, but it does not execute `ls -la /data`. Option B is wrong because `kubectl run` creates a new pod from an image, not executes a command inside an existing running pod; it would launch a new pod and run `ls -la /data` in that new pod, not the target pod. Option D is wrong because `kubectl attach` attaches to a running container's main process (stdin/stdout/stderr), not to execute a new command; it does not support running `ls -la /data` as a separate process.

Full explanation →

596

MCQhard

You have a HorizontalPodAutoscaler (HPA) that targets CPU utilization at 50%. The current average CPU utilization is 80%. The HPA has a stabilization window of 300 seconds and a scale-down policy with a periodSeconds of 60. CPU utilization drops to 40%. How long will it take for the HPA to begin scaling down?

A.After 300 seconds

B.Immediately

C.After 60 seconds

D.After 360 seconds

AnswerA

The HPA waits the stabilization window before scaling down.

Why this answer

The stabilization window is the time the HPA waits before considering a scale-down decision. It will wait 300 seconds after the utilization drops below the target.

Full explanation →

597

MCQmedium

A pod runs as user ID 1000. The container image includes a binary that expects to run as root. Which SecurityContext setting can allow the binary to run with root-like privileges while still running the container as non-root?

A.Add the SYS_ADMIN capability under securityContext.capabilities.add

B.Set securityContext.privileged: true

C.Set securityContext.runAsUser: 0

D.Set securityContext.allowPrivilegeEscalation: true

AnswerC

Setting runAsUser to 0 makes the container run as root, fulfilling the binary's requirement.

Why this answer

Option C is correct because setting `securityContext.runAsUser: 0` overrides the pod's user ID (1000) for this specific container, making it run as root (UID 0). This allows the binary that expects root privileges to execute without changing the pod-level security context or granting unnecessary capabilities.

Exam trap

The trap here is that candidates confuse `runAsUser: 0` with a security risk, when in fact it is a precise way to run a specific container as root without elevating the entire pod or using privileged mode.

How to eliminate wrong answers

Option A is wrong because adding the SYS_ADMIN capability grants broad administrative privileges but does not change the user ID; the binary would still run as UID 1000 and fail if it requires root. Option B is wrong because setting `privileged: true` gives the container almost all host capabilities and disables most security restrictions, which is excessive and violates the requirement to run as non-root. Option D is wrong because `allowPrivilegeEscalation: true` only permits processes to gain more privileges than their parent (e.g., via setuid binaries), but it does not change the initial user ID; the binary still runs as UID 1000 unless a setuid root binary is present.

Full explanation →

598

Multi-Selecthard

Which THREE of the following are valid methods to view logs of a container that has already terminated?

Select 3 answers

A.kubectl logs <pod> --all-containers

B.kubectl logs <pod> --tail=50

C.kubectl logs --all

D.kubectl logs <pod> --previous

E.kubectl logs <pod> -p

AnswersB, D, E

Shows last 50 lines of logs (if container still exists).

Why this answer

Option B is correct because `kubectl logs <pod> --tail=50` retrieves the last 50 lines of logs from the specified pod's container. Even if the container has terminated, the logs are still available from the pod's log history, and `--tail` limits the output to the most recent entries, which is useful for debugging recent failures.

Exam trap

CNCF often tests the distinction between `--previous` (which retrieves logs from a terminated container that has been restarted) and `--tail` (which limits output lines), and candidates may mistakenly think `--all-containers` or `--all` are valid for terminated containers without understanding the need for `--previous`.

Full explanation →

599

MCQhard

You have a NetworkPolicy that allows ingress from pods with label 'app: frontend' in any namespace, and also allows ingress from the IP range '10.0.0.0/8'. The policy is not working as expected. Which YAML snippet correctly implements both requirements?

A.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - from: - ipBlock: cidr: 10.0.0.0/8

B.ingress: - from: - namespaceSelector: {} - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

C.ingress: - from: - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

D.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

AnswerA

This correctly separates the two rules: one for pods with label app: frontend in any namespace, and one for the IP range.

Why this answer

To allow ingress from pods with a specific label in any namespace, you use namespaceSelector: {} and podSelector with matchLabels. For IP range, you use ipBlock. Both rules should be in the ingress array.

Option B is correct. Option A uses namespaceSelector with podSelector but the namespaceSelector {} is missing. Option C uses ipBlock incorrectly.

Option D uses only from with both, but the structure is wrong.

Full explanation →

600

MCQhard

During a rolling update of a Deployment, you notice that new pods are failing readiness probes. The rollout is stalled. Which command would you use to abort the rollout and revert to the previous revision?

A.kubectl rollout undo deployment <name>

B.kubectl rollout pause deployment <name>

C.kubectl rollout resume deployment <name>

D.kubectl delete deployment <name> --cascade=false

AnswerA

Correct command to rollback.

Why this answer

'kubectl rollout undo deployment <name>' reverts the rollout to the previous revision. Option A is correct.

Full explanation →

Page 8 of 14

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Practice CKAD by domain

Target a specific domain to shore up weak areas.

Application Design and Build Application Deployment Application Environment, Configuration and Security Application Observability and Maintenance Services and Networking

See all domains with question counts →