Certified Kubernetes Application Developer CKAD CKAD Questions 751–825 | Page 11/12

751

MCQmedium

A pod manifest includes the following securityContext: securityContext: { runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000 }. What UID will be used for processes in the container?

A.0 (root)

B.3000

C.2000

D.1000

AnswerD

runAsUser: 1000 is the correct UID because it directly sets the numeric user ID for the container's primary process. When a container starts, the process is launched with this UID unless an image-level USER directive is overridden by this field. The securityContext's runAsUser takes precedence over the image's default user, so the process runs as UID 1000.

Why this answer

The `runAsUser` field in the pod's securityContext explicitly sets the user ID (UID) for all processes in the container. In this manifest, `runAsUser: 1000` overrides the default UID (usually 0, root) and ensures that the container's main process runs with UID 1000. The `runAsGroup` and `fsGroup` fields affect group IDs and file ownership, not the process UID.

Exam trap

CNCF often tests the distinction between `runAsUser` (process UID), `runAsGroup` (process GID), and `fsGroup` (volume ownership GID), and the trap here is that candidates confuse `fsGroup` or `runAsGroup` with the process UID, leading them to select 2000 or 3000 instead of 1000.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` explicitly overrides the default root UID (0), so processes do not run as root. Option B is wrong because `runAsGroup: 3000` sets the primary group ID (GID) for the process, not the UID. Option C is wrong because `fsGroup: 2000` is used to set the group ownership of mounted volumes and any files created in them, but it does not affect the UID of the container's processes.

Full explanation →

752

MCQeasy

Which of the following Ingress controllers is commonly used in Kubernetes?

A.IIS

B.Apache

C.NGINX

D.Tomcat

AnswerC

NGINX Ingress Controller is the de facto standard for Kubernetes Ingress due to its robust reverse proxy and load balancing capabilities built on the battle-tested NGINX engine. It runs as a pod inside the cluster and continuously watches the Kubernetes API for Ingress resources, translating them into NGINX configuration with minimal latency. It supports advanced features like SSL/TLS termination, path-based routing, canary releases, and fine-grained annotations, making it the most widely adopted controller across on-prem and cloud deployments.

Why this answer

NGINX is the most widely adopted Ingress controller in Kubernetes, providing a reverse proxy that routes external HTTP/HTTPS traffic to services based on Ingress resource rules. It is officially maintained by the Kubernetes community and supports advanced features like SSL termination, load balancing, and path-based routing, making it the default choice for many production clusters.

Exam trap

The CKAD exam often tests the distinction between general-purpose web servers (like Apache, Tomcat, IIS) and purpose-built Kubernetes Ingress controllers (like NGINX, Traefik, HAProxy), leading candidates to confuse a web server's ability to serve content with its ability to dynamically route traffic based on Kubernetes Ingress resources.

How to eliminate wrong answers

Option A is wrong because IIS (Internet Information Services) is a Windows-based web server from Microsoft, not a Kubernetes Ingress controller, and it lacks native integration with Kubernetes Ingress resources. Option B is wrong because Apache HTTP Server is a general-purpose web server, not designed as a Kubernetes Ingress controller; it does not natively watch Kubernetes API for Ingress rule changes. Option D is wrong because Tomcat is a Java servlet container and web server, not an Ingress controller; it cannot process Kubernetes Ingress objects or provide the required reverse proxy functionality for cluster ingress.

Full explanation →

753

MCQhard

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

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

B.selector: {app: api} and adjust the number of replicas in each Deployment to achieve the desired ratio (e.g., 9 stable, 1 canary)

C.selector: {app: api, version: stable}

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

AnswerB

Using a single Service with the broad selector `app: api` is the correct native Kubernetes approach because it makes the Service's Endpoints object include pods from both the stable and canary Deployments simultaneously. The kube-proxy component (or the in-cluster DNS/round-robin mechanism) then picks endpoints for each new connection uniformly, so the fraction of traffic each version receives is directly proportional to the number of ready pods it contributes—for 9 stable and 1 canary pod, roughly 90% of connections go to stable and 10% to canary. This ratio can be tuned by scaling the `replicas` field in each Deployment, but you cannot get fine-grained percentages because each pod is an equal unit and there is no weighting factor beyond pod count.

Why this answer

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

Exam trap

The trap here is that candidates may think annotations or custom selectors can control traffic weight, but Kubernetes Services only distribute traffic proportionally to the number of ready Pods matching the selector.

How to eliminate wrong answers

Option A is wrong because Kubernetes Services do not support a 'traffic-weight' annotation; traffic distribution is based on the number of ready Pods, not annotations. Option C is wrong because using selector '{app: api, version: stable}' would route 100% of traffic to the stable Deployment, ignoring the canary entirely. Option D is wrong because creating two separate Services with DNS weighting is not a native Kubernetes feature and would require external tools or manual DNS management, which is not a standard Service configuration.

Full explanation →

754

MCQeasy

Which kubectl command creates a Secret from literal username and password values?

A.kubectl create secret generic my-secret --literal username=admin password=secret123

B.kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123

C.kubectl create secret generic my-secret --from-file=username --from-file=password

D.kubectl create secret generic my-secret --from-env-file=creds.txt

AnswerB

The --from-literal flag supplies key-value pairs directly on the command line, creating a generic Secret without files. This satisfies the requirement to build a Secret from literal username and password values in a single imperative command.

Why this answer

`kubectl create secret generic` with `--from-literal` is the proper syntax for specifying literal key-value pairs directly in the command. Each literal must be prefixed with `--from-literal=key=value`, and multiple literals can be provided to create a Secret containing both the username and password keys.

Exam trap

The trap here is that candidates confuse `--from-literal` with the non-existent `--literal` flag, or assume that multiple key-value pairs can be passed in a single `--from-literal` argument, leading them to choose Option A.

How to eliminate wrong answers

Option A is wrong because it uses `--literal` instead of the correct `--from-literal` flag, and the syntax `--literal username=admin password=secret123` is invalid — kubectl requires each literal to be specified with its own `--from-literal=key=value` flag. Option C is wrong because `--from-file` creates a Secret from file contents, not literal values; it would read the files named 'username' and 'password' from the filesystem, not use inline strings. Option D is wrong because `--from-env-file` imports key-value pairs from a file in the format `KEY=VALUE`, but it does not accept literal values directly on the command line.

Full explanation →

755

MCQeasy

A developer wants to view the resource usage of all containers in a specific pod. Which command should they use?

A.kubectl top pods --all-namespaces

B.kubectl top pods

C.kubectl top pod <pod>

D.kubectl top pod <pod> --containers

AnswerD

kubectl top pod <pod> --containers is the correct command because it lists each container within the specified pod separately, showing its individual CPU and memory consumption. This gives the developer the exact per-container resource usage needed, making it the only option that satisfies the requirement directly.

Why this answer

`kubectl top pod <pod> --containers` displays per-container CPU and memory metrics for a specific pod, which is exactly what the developer needs to view resource usage of all containers within that pod. The `--containers` flag is essential to break down the pod-level metrics into individual container-level metrics.

Exam trap

The trap here is that candidates often assume `kubectl top pod <pod>` alone shows container-level details, but without the `--containers` flag it only shows pod-level aggregates, leading them to choose option C instead of D.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods --all-namespaces` shows pod-level resource usage across all namespaces, not per-container metrics for a specific pod. Option B is wrong because `kubectl top pods` shows pod-level resource usage in the current namespace, but does not break down usage by individual containers. Option C is wrong because `kubectl top pod <pod>` shows aggregate resource usage for the entire pod, not per-container details, which fails to meet the requirement of viewing all containers' usage.

Full explanation →

756

MCQmedium

You need to mount a Secret 'db-secret' as a volume in a pod, making its keys appear as individual files. Which volume definition is correct?

A.volumes: - name: secret-vol emptyDir: medium: Secret

B.volumes: - name: secret-vol secret: secretName: db-secret items: - key: password path: credentials.txt

C.volumes: - name: secret-vol configMap: name: db-secret

D.volumes: - name: secret-vol secret: secretName: db-secret

AnswerD

This is the correct way to mount a Secret as a volume. The secret volume source with secretName: db-secret tells Kubernetes to create a volume backed by the db-secret Secret. By default, the volume contains a separate file for each key in the Secret, with the filename matching the key and the file content holding the corresponding decoded value. This satisfies the requirement of mounting the db-secret secret as a volume with all keys exposed as individual files.

Why this answer

It defines a volume of type `secret` with the `secretName` field set to `db-secret`, which mounts the entire Secret as a volume. By default, each key in the Secret becomes a file named after the key, satisfying the requirement that keys appear as individual files.

Exam trap

The trap here is that candidates often confuse the `items` field (which projects specific keys into custom filenames) with the default behavior (which mounts all keys as individual files), leading them to pick Option B even though it does not meet the requirement of making all keys appear as individual files.

How to eliminate wrong answers

Option A is wrong because `emptyDir` volumes are ephemeral storage directories, not Secret mounts; the `medium` field accepts values like `Memory`, not `Secret`. Option B is wrong because it uses the `items` field to project only a single key (`password`) into a file named `credentials.txt`, which does not make all keys appear as individual files. Option C is wrong because `configMap` references a ConfigMap, not a Secret; Secrets and ConfigMaps are separate resource types with different handling (e.g., Secrets are base64-encoded).

Full explanation →

757

Multi-Selectmedium

Which THREE of the following are valid patterns for multi-container pods?

Select 3 answers

A.Init

B.Ambassador

C.Adapter

D.Sidecar

E.Daemon

AnswersB, C, D

The ambassador pattern places a proxy container in the same pod as the main container, intercepting all network traffic destined for external services. The main container only needs to connect to localhost, while the ambassador transparently handles remote connectivity, TLS termination, authentication, or load balancing, enabling the application to be simpler and more portable.

Why this answer

The Ambassador pattern is a valid multi-container pod pattern where a proxy container handles network communication on behalf of the main application container, abstracting external service connectivity. This pattern is commonly implemented with tools like Envoy or a custom sidecar proxy that manages TLS termination, service discovery, or circuit breaking, allowing the main container to connect to localhost while the ambassador handles remote connections.

Exam trap

The CKAD exam often tests the distinction between pod-level patterns (sidecar, ambassador, adapter) and cluster-level controllers (DaemonSet, Job, ReplicaSet), leading candidates to confuse 'Daemon' as a multi-container pattern when it is actually a controller for running pods across nodes.

Full explanation →

758

MCQeasy

Which Dockerfile instruction sets a default command that can be overridden by arguments passed to 'docker run'?

A.ENTRYPOINT

B.EXPOSE

C.CMD

D.RUN

AnswerC

The CMD instruction specifies a default command and optional parameters that Docker executes when the container starts, providing a baseline behavior for the image. It is designed to be overridden easily: when you run the container and supply your own command-line arguments, they replace the CMD entirely. Thus CMD precisely matches the requirement of setting a default command that can be overridden.

Why this answer

The CMD instruction in a Dockerfile sets a default command that runs when a container starts. This default can be overridden by providing arguments directly to 'docker run' after the image name, making it the correct choice for a command that is intended to be easily replaced.

Exam trap

The CKAD exam often tests the distinction between CMD and ENTRYPOINT, and the trap here is that candidates confuse CMD (which can be overridden) with ENTRYPOINT (which requires the --entrypoint flag to override), leading them to incorrectly select ENTRYPOINT as the instruction that accepts overrides from 'docker run'.

How to eliminate wrong answers

Option A is wrong because ENTRYPOINT defines a fixed command that cannot be overridden by 'docker run' arguments unless the --entrypoint flag is used; it is designed to set the main executable. Option B is wrong because EXPOSE only documents which ports the container listens on at runtime; it does not execute any command. Option D is wrong because RUN executes commands during the image build process, not at container startup, so it cannot be overridden by 'docker run'.

Full explanation →

759

MCQeasy

Which kubectl command streams logs from a pod named 'web-pod' in real-time?

A.kubectl logs --since=5m web-pod

B.kubectl logs --tail=100 web-pod

C.kubectl logs -f web-pod

D.kubectl logs web-pod

AnswerC

The -f flag follows the log stream, keeping the connection open and outputting new entries as they are generated rather than returning existing logs and exiting. This delivers the real-time streaming required for the named pod.

Why this answer

The `-f` flag (short for `--follow`) tells kubectl to stream logs from the pod in real-time, similar to `tail -f` on a file. This is essential for live monitoring of application output as it is generated.

Exam trap

The trap here is that candidates may confuse flags like `--tail` or `--since` with real-time streaming, not realizing that only `-f` (or `--follow`) provides continuous log output.

How to eliminate wrong answers

Option A is wrong because `--since=5m` retrieves logs from the last 5 minutes but does not stream them; it prints the logs and exits. Option B is wrong because `--tail=100` shows only the last 100 lines of logs and then exits, without following new output. Option D is wrong because `kubectl logs web-pod` prints all available logs from the pod and exits, providing no real-time streaming capability.

Full explanation →

760

Multi-Selectmedium

You need to check the resource usage of nodes and pods in your cluster. Which TWO commands should you use? (Choose two)

Select 2 answers

A.kubectl top nodes

B.kubectl logs

C.kubectl cluster-info

D.kubectl describe pod

E.kubectl top pods

AnswersA, E

kubectl top nodes queries the metrics server to retrieve CPU and memory utilization for each cluster node, aggregated across all pods. It displays both the current usage and percentage of allocatable capacity, providing a quick cluster-wide view of resource pressure. This command is essential for identifying overall node resource saturation and planning capacity, but it requires the metrics server to be installed and operational.

Why this answer

A is correct because `kubectl top nodes` retrieves real-time CPU and memory usage metrics for all nodes in the cluster, sourced from the metrics server (which collects resource usage from kubelets via the Summary API). This command is the standard way to check node-level resource consumption in Kubernetes.

Exam trap

The CKAD exam often tests the distinction between `kubectl top` (actual resource usage) and `kubectl describe` (resource requests/limits), leading candidates to mistakenly choose `kubectl describe pod` thinking it shows live usage.

Full explanation →

761

MCQhard

A NetworkPolicy with the following spec is applied to a namespace. What is the effect? spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 10.0.0.0/8 except: - 10.0.1.0/24 egress: - to: - ipBlock: cidr: 0.0.0.0/0

A.Deny all ingress and egress traffic

B.Allow all ingress and egress traffic

C.Deny all ingress traffic except from 10.0.0.0/8 excluding 10.0.1.0/24; allow all egress

D.Allow ingress from 10.0.1.0/24 only

AnswerC

This is accurate: the ingress rule uses an ipBlock with cidr 10.0.0.0/8 and except 10.0.1.0/24, which permits traffic from any address in the /8 range except that specific /24, and denies everything else by default isolation. Since no egress rule is defined and policyTypes only includes Ingress, egress traffic remains unrestricted, matching the 'allow all egress' clause.

Why this answer

The NetworkPolicy selects all pods in the namespace (empty podSelector matches all pods) and explicitly defines both Ingress and Egress policy types. The ingress rule allows traffic only from the 10.0.0.0/8 range, except 10.0.1.0/24, effectively denying all other ingress. The egress rule allows all outbound traffic to 0.0.0.0/0, so egress is unrestricted.

Exam trap

The trap here is that candidates often forget that an empty podSelector selects all pods, and that listing a policyType without a matching rule defaults to deny, but a rule with 0.0.0.0/0 for egress explicitly allows all outbound traffic.

How to eliminate wrong answers

Option A is wrong because the policy does not deny all egress; it explicitly allows egress to 0.0.0.0/0. Option B is wrong because the ingress rule is restrictive, not permissive; it only allows traffic from a specific IP range with an exception, so not all ingress is allowed. Option D is wrong because the ingress rule denies traffic from 10.0.1.0/24 (the except block) and allows traffic from the rest of 10.0.0.0/8, not the other way around.

Full explanation →

762

MCQeasy

You need to forward a local port to port 8080 on a pod named 'my-pod' in the 'default' namespace. Which kubectl command should you use?

A.kubectl port-forward pod/my-pod 8080:80

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

C.kubectl forward pod/my-pod 8080:8080

D.kubectl port-forward my-pod 8080

AnswerB

This command is correct because it explicitly names a pod resource using the 'pod/' prefix and maps local port 8080 to the pod's port 8080, exactly as required. The syntax 'kubectl port-forward pod/my-pod 8080:8080' creates a tunnel from localhost:8080 to port 8080 on the specified pod, allowing direct access to the application running there. It is the only option that both uses the correct verb and targets the pod with the proper port pairing.

Why this answer

The `kubectl port-forward` command requires the resource type (pod/) and the correct port mapping syntax. The question specifies forwarding a local port to port 8080 on the pod, so the local port is 8080 and the pod port is 8080, making `8080:8080` the correct mapping. The full command `kubectl port-forward pod/my-pod 8080:8080` establishes a tunnel from localhost:8080 to the pod's port 8080.

Exam trap

The trap here is that candidates often forget to include the resource type prefix (`pod/`) or confuse the port mapping order, leading them to choose options like A or D, which either map to the wrong port or omit the required resource type.

How to eliminate wrong answers

Option A is wrong because it maps local port 8080 to pod port 80, but the question requires forwarding to port 8080 on the pod, not port 80. Option C is wrong because `kubectl forward` is not a valid kubectl subcommand; the correct subcommand is `port-forward`. Option D is wrong because it omits the required resource type prefix `pod/`; without it, kubectl cannot determine the resource type and will fail with an error.

Full explanation →

763

MCQmedium

You want to debug a pod that has no shell or debugging tools installed. Which feature allows you to temporarily add a sidecar container with debugging tools to a running pod?

A.kubectl exec -it my-pod -- /bin/bash

B.kubectl cp /tmp/debug-tool my-pod:/tmp/

C.kubectl debug -it my-pod --image=busybox --target=my-container

D.kubectl port-forward my-pod 8080:80

AnswerC

kubectl debug -it my-pod --image=busybox --target=my-container is correct because it creates a new ephemeral container in the same pod, sharing the pod's network namespace and, with --target, the process namespace of my-container. Busybox comes with a built-in ash shell and standard diagnostic utilities (ps, netstat, ls, cat), giving you an interactive shell without needing anything preinstalled in the original container. The ephemeral container has its own filesystem and can run commands that see and signal the target container's processes, exactly what you need to debug a pod that lacks a shell or debugging tools.

Why this answer

`kubectl debug` allows you to create an ephemeral container (sidecar) in a running pod, using a specified image (e.g., busybox) that includes debugging tools, without requiring the original container to have a shell or tools. This feature leverages the Ephemeral Containers alpha feature (enabled by default in Kubernetes 1.23+) to inject a temporary container into an existing pod for debugging purposes.

Exam trap

The trap here is that candidates often assume `kubectl exec` can always provide a shell, but the CKAD exam tests the specific scenario where the container lacks a shell or tools, making `kubectl debug` the only viable option for injecting debugging capabilities.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it my-pod -- /bin/bash` attempts to run a shell inside the existing container, which fails if the container has no shell or debugging tools installed. Option B is wrong because `kubectl cp` copies files into the container's filesystem but does not install or run debugging tools; it requires the container to already have a shell or executable to use the copied files. Option D is wrong because `kubectl port-forward` forwards network traffic to a pod's port and does not provide any debugging tools or shell access.

Full explanation →

764

MCQmedium

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory'. What is the most likely cause?

A.The pod's resource requests exceed the available node resources

B.The pod uses too many secrets

C.The pod's resource limits are too low

D.The pod's container is failing health checks

AnswerA

The Kubernetes scheduler selects a node based on the resource requests (CPU and memory) declared in the pod spec. If no node has enough allocatable resources to satisfy those requests after accounting for the requests of existing pods, the scheduler cannot place the pod, leaving it in Pending state. This is the most common cause of Pending, and `kubectl describe` typically shows FailedScheduling events with reasons like 'Insufficient cpu' or 'Insufficient memory'.

Why this answer

The event '0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory' indicates that the Kubernetes scheduler could not find any node that satisfies the pod's resource requests. The pod's resource requests (spec.containers[].resources.requests) define the minimum CPU and memory the pod requires to run. If the sum of requests across all pods on a node exceeds the node's allocatable resources, the scheduler marks the node as unschedulable for that pod, leaving it in Pending state.

Exam trap

The trap here is that candidates often confuse resource requests with resource limits, thinking that low limits cause scheduling failures, but Kubernetes only uses requests for scheduling decisions, not limits.

How to eliminate wrong answers

Option B is wrong because using too many secrets does not affect pod scheduling; secrets are mounted as files or environment variables and do not consume node resources like CPU or memory. Option C is wrong because resource limits (spec.containers[].resources.limits) are not used for scheduling decisions; limits only control how much a container can use after it starts, and low limits would not cause a Pending state. Option D is wrong because failing health checks (liveness/readiness probes) cause the pod to be restarted or marked as Unhealthy after it is already running, not while it is still in Pending state before any container starts.

Full explanation →

765

MCQhard

The Pod 'myapp' is in CrashLoopBackOff. Based on the exhibit, what is the most likely cause?

A.The init container failed to complete.

B.The readiness probe is misconfigured.

C.The container is trying to bind to a port already used by a sidecar or previous instance.

D.The liveness probe is failing and restarting the container.

AnswerC

The container is trying to bind to a port already used by a sidecar or previous instance. The error 'address already in use' (EADDRINUSE) indicates that the application's listen() call failed because the port is already occupied in the shared network namespace. In a pod, containers share the same network namespace, so a sidecar bound to the same port would cause this conflict. Additionally, if a previous instance of the pod is still shutting down and holding the socket in TIME_WAIT, a rapid restart can trigger the same bind failure.

Why this answer

The Pod is in CrashLoopBackOff, which indicates the container repeatedly crashes. The most likely cause is that the container is trying to bind to a port already in use by a sidecar or a previous instance of the same container that hasn't fully terminated. This is a common scenario when a sidecar container (e.g., a logging proxy) binds to the same port, or when the container's port is not released quickly enough after a restart, leading to an immediate crash on startup.

Exam trap

The trap here is that candidates often assume CrashLoopBackOff is always caused by a failing liveness probe (Option D), but they overlook that the container must actually start and run for the liveness probe to be checked; if the container crashes immediately on startup (e.g., due to port conflict), the liveness probe never even runs, and the root cause is a startup failure, not a probe failure.

How to eliminate wrong answers

Option A is wrong because if the init container had failed to complete, the Pod would remain in Init:CrashLoopBackOff or Init:Error, not in CrashLoopBackOff for the main container. Option B is wrong because a misconfigured readiness probe would cause the container to be marked as not ready (removed from service endpoints), but it would not cause the container to crash or enter CrashLoopBackOff; the container would continue running. Option D is wrong because a failing liveness probe would cause the container to be restarted, but the Pod would show a restart count and potentially a CrashLoopBackOff only if the container crashes immediately after restart; however, the question asks for the 'most likely cause' given the exhibit (not provided here), and port binding conflicts are a classic cause of immediate crash on startup, whereas liveness probe failures typically occur after the container has started and run for a short time.

Full explanation →

766

MCQeasy

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

A.The selector does not match the pod labels

B.The liveness probe targets port 8080, but the container only listens on port 80

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

D.The container image nginx:1.21 does not exist

AnswerB

The livenessProbe sends an HTTP GET to port 8080 on the container's IP. Nginx by default listens on port 80 inside the container, so the kubelet's request to 8080 will get a connection refused error. Since the probe never succeeds, the kubelet marks the container unhealthy and after three consecutive failures kills the container. The container then restarts, but the same probe failure repeats, resulting in CrashLoopBackOff.

Why this answer

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

Exam trap

CNCF often tests the distinction between probe misconfiguration (wrong port/path) and other failure modes like image errors or selector mismatches, tempting candidates to overthink with options like initialDelaySeconds.

How to eliminate wrong answers

Option A is wrong because if the selector did not match pod labels, the Deployment would not manage the pods at all; pods would be created but not controlled, and they would not enter CrashLoopBackOff. Option C is wrong because a short initialDelaySeconds might cause temporary failures, but the pod would eventually succeed once the app is ready; CrashLoopBackOff indicates persistent failure, not just early probes. Option D is wrong because if the image nginx:1.21 did not exist, the pods would fail with ImagePullBackOff, not CrashLoopBackOff.

Full explanation →

767

MCQmedium

You have a Kustomize overlay that sets 'replicas: 5' in a patch, but the base Deployment has 'replicas: 3'. What is the final number of replicas after applying 'kubectl apply -k overlay/'?

A.3

B.8

C.It depends on the strategy

D.5

AnswerD

The overlay explicitly sets replicas: 5 in its patch, so Kustomize uses exactly that value in the final output. Since overlays take precedence over base values, the base's original replica count is overwritten. This is the core of how Kustomize enables environment-specific customizations: the overlay's patch always wins for fields it specifies, making 5 the correct and deterministic result.

Why this answer

In Kustomize, overlays are applied on top of the base, and patches override the base values. Since the overlay explicitly sets 'replicas: 5' via a patch, it replaces the base value of 3. The final Deployment will have 5 replicas, making D correct.

Exam trap

The trap here is that candidates mistakenly think Kustomize merges or adds values from base and overlay, similar to Helm's merge behavior, when in fact Kustomize patches override scalar fields completely.

How to eliminate wrong answers

Option A is wrong because the base value of 3 is overridden by the overlay patch, not preserved. Option B is wrong because Kustomize patches replace values by default, not merge or add them; replicas are not summed. Option C is wrong because there is no 'strategy' that changes the override behavior; Kustomize's patch mechanism is deterministic and always applies the patch value.

Full explanation →

768

MCQeasy

You want to expose a Deployment named 'nginx' on port 80 using a LoadBalancer service. Which YAML snippet is correct?

A.apiVersion: v1 kind: Service metadata: name: nginx-svc spec: type: NodePort ports: - port: 80 selector: app: nginx

B.apiVersion: v1 kind: Service metadata: name: nginx-svc spec: type: LoadBalancer ports: - port: 80 targetPort: 80 selector: app: nginx

C.apiVersion: v1 kind: Service metadata: name: nginx-svc spec: type: LoadBalancer ports: - port: 80 selector: app: nginx

D.apiVersion: apps/v1 kind: Service metadata: name: nginx-svc spec: type: LoadBalancer ports: - port: 80 selector: app: nginx

AnswerC

This is the correct minimal LoadBalancer Service definition. The apiVersion v1 and kind Service are correct, and setting type: LoadBalancer instructs the cluster to provision a cloud load balancer that forwards traffic to port 80. The selector app: nginx matches the deployment's pods, and since targetPort is omitted, it defaults to port (80) — a trick that keeps the manifest concise and is preferred in CKAD.

Why this answer

Option C is correct because it defines a Service of type LoadBalancer, exposing the 'nginx' Deployment on port 80. The apiVersion v1 is appropriate for a Service, and the selector matches the Deployment's labels. Option B includes an unnecessary explicit targetPort: 80, making it less preferred for the CKAD exam, which expects the most concise correct YAML.

Option A uses NodePort instead of LoadBalancer, and Option D uses an incorrect apiVersion.

Exam trap

The trap here is that candidates may confuse apiVersion apps/v1 with v1, or think that targetPort must be explicitly set. Option B is not the best answer because it includes unnecessary fields; the exam expects the most concise correct YAML.

How to eliminate wrong answers

Option A is wrong because it uses type NodePort instead of LoadBalancer, which does not provision an external load balancer and only exposes the service on a static port on each node. Option B is wrong because it explicitly sets targetPort: 80, which is redundant but not incorrect; however, the question asks for the correct snippet, and C is more concise and standard. Option D is wrong because it uses apiVersion apps/v1, which is for Deployments, not Services; Services must use apiVersion v1.

Full explanation →

769

MCQeasy

Which of the following Service types exposes a pod on a static port on each node's IP address?

A.LoadBalancer

B.ExternalName

C.ClusterIP

D.NodePort

AnswerD

NodePort allocates a static port from the default range 30000–32767 on every node's IP address, forwarding traffic to the targeted pods. ClusterIP exposes only a virtual internal address, and LoadBalancer builds on NodePort with an external cloud load balancer, so NodePort uniquely satisfies the static-port-per-node constraint.

Why this answer

NodePort is the correct answer because it exposes a pod on a static port (in the range 30000-32767) on every node's IP address. When a Service of type NodePort is created, Kubernetes opens that port on all nodes in the cluster, forwarding traffic to the target pods. This allows external access to the pod via any node's IP and the assigned static port.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer also exposes a static port on each node, but LoadBalancer actually relies on NodePort internally and adds an external LB, not a direct per-node static port exposure.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the service via an external load balancer (e.g., cloud provider's LB) and does not directly expose a static port on each node's IP; it typically builds on NodePort but adds a load balancer frontend. Option B is wrong because ExternalName maps a service to a DNS name (CNAME record) and does not expose any port or pod at all; it is used for external service references. Option C is wrong because ClusterIP exposes the service only on a cluster-internal IP, reachable only within the cluster, not on each node's IP address.

Full explanation →

770

MCQmedium

A pod named 'db-backup' is in CrashLoopBackOff. The team needs to understand why it keeps crashing. Which approach should be taken first to diagnose the issue?

A.Increase the restart policy to Always

B.Run kubectl describe pod

C.View the logs of the pod using kubectl logs

D.Check the pod's events with kubectl get events

AnswerC

kubectl logs reads the container's captured stdout/stderr and directly exposes the panic, exception, or configuration error triggering the CrashLoopBackOff. Since the pod is in CrashLoopBackOff, use kubectl logs db-backup --previous to retrieve logs from the last terminated instance, as the current container may have already exited. This is the fastest way to identify the exact failing statement and then patch the manifest or fix the code.

Why this answer

C is correct because `kubectl logs` directly shows the stdout/stderr output from the container's main process, which typically contains the error message or stack trace explaining why the application crashed. Since the pod is in CrashLoopBackOff, the container is repeatedly starting and failing, so viewing the logs from the last (or previous) attempt is the fastest way to identify the root cause, such as a missing configuration file, a failed dependency, or an unhandled exception.

Exam trap

The trap here is that candidates often choose `kubectl describe pod` (Option B) because it shows events and exit codes, but they overlook that `kubectl logs` directly reveals the application's error message, which is the most efficient first step for debugging a crash.

How to eliminate wrong answers

Option A is wrong because changing the restart policy to Always does not diagnose the crash; it only changes the behavior after a crash, and the pod already has a restart policy (default Always) that is causing the CrashLoopBackOff. Option B is wrong because `kubectl describe pod` provides metadata, events, and status but does not show the application's stdout/stderr logs; it can show why the container exited (e.g., exit code) but not the specific error message from the application. Option D is wrong because `kubectl get events` shows cluster-level events (e.g., pulling images, scheduling) but not the application's internal error output; it may show the container restart count but not the crash reason.

Full explanation →

771

MCQmedium

A user runs 'kubectl get endpoints my-service' and sees no endpoints listed. The service has a selector 'app: my-app'. Pods with that label exist and are running. What is the most likely cause?

A.The service selector does not match the pod labels

B.The pods are not assigned an IP address

C.The service name is incorrect

D.The pods are not ready (readiness probe failing)

AnswerD

Even if readiness probe fails, the endpoints would still exist if the selector matches; the pod would be removed from endpoints only if it fails readiness, but initially endpoints would have been populated. If no endpoints at all, selector mismatch is the first thing to check.

Why this answer

In Kubernetes, a Service creates Endpoints only for pods that match its selector and are ready. Because the pods are labeled app: my-app and match the selector, the missing endpoints indicate the pods are not passing their readiness probes.

Exam trap

The trap is that 'running' does not equal 'ready'. A pod must be both selected and ready to appear in Endpoints. Readiness probes determine readiness.

How to eliminate wrong answers

Option B is wrong because pods that are running and have an IP address assigned by the CNI plugin; if they were not assigned an IP, they would not reach the Running phase. Option C is wrong because the question states the user runs 'kubectl get endpoints my-service', which implies the service name is correct and the command succeeds; an incorrect service name would produce a 'not found' error, not an empty endpoints list. Option D is wrong because while a failing readiness probe can cause endpoints to be removed, the question states pods exist and are running, but does not specify they are ready; however, the most likely cause given the direct mismatch of selector and labels is the selector mismatch, not a readiness probe issue, and readiness probes affect endpoint inclusion only after the selector match is satisfied.

Full explanation →

772

MCQmedium

You have a Deployment with 3 replicas. You create a Service with 'clusterIP: None'. What is the effect on pod DNS?

A.Each pod gets its own DNS record in the form <pod-ip>.<service>.<namespace>.svc.cluster.local

B.DNS returns the IPs of all matching pods.

C.The Service name does not resolve to any IP; DNS fails.

D.The Service name resolves to a single virtual IP that load balances across pods.

AnswerB

With a headless Service (clusterIP: None) that has a selector matching the Deployment’s pods, the DNS name resolves to all matching pod IPs as separate A records. A DNS query for the Service name returns the list of endpoint IPs, which corresponds to the three running replicas. This design lets clients directly connect to individual pods for client-side load balancing or service discovery.

Why this answer

When a Service is created with `clusterIP: None`, it becomes a headless Service. For a headless Service, DNS is configured to return the IP addresses of all matching pods (the endpoints) rather than a single virtual IP. This allows client applications to discover and connect to individual pods directly, which is essential for stateful workloads like databases.

Exam trap

The trap here is that candidates confuse headless Services with regular ClusterIP Services, assuming 'None' means no DNS resolution at all, when in fact it changes the DNS behavior to return pod IPs directly.

How to eliminate wrong answers

Option A is wrong because DNS records for headless Services use the pod's hostname (derived from the pod name) and the service name, not the pod IP; the format is `<pod-hostname>.<service>.<namespace>.svc.cluster.local`. Option C is wrong because the Service name does resolve — it returns the A/AAAA records for all matching pods, not a failure. Option D is wrong because that describes a regular ClusterIP Service, which uses a single virtual IP for load balancing; a headless Service explicitly avoids this.

Full explanation →

773

MCQhard

You are asked to implement a blue-green deployment using Kubernetes Deployments and Services. You have a blue Deployment with label 'version: blue' and a green Deployment with label 'version: green'. Both have selector 'app: myapp'. You need a Service that initially points to blue. How should you configure the Service to switch to green without downtime?

A.Change the blue Deployment's pod label to 'version: green' and delete green Deployment

B.Update the Service's label selector to 'app: myapp, version: green'

C.Delete the Service and recreate it with the new selector

D.Update the Service's cluster IP to point to green pods

AnswerB

Updating the Service's label selector to 'app: myapp, version: green' is the canonical blue-green switch: the Endpoints controller immediately recalculates the endpoint set to include only green pods, so new traffic flows to green while blue receives no new connections. Because this is a single atomic change (e.g., kubectl patch), there is zero downtime, and the blue Deployment remains intact for instant rollback if green fails.

Why this answer

Updating the Service's label selector to 'app: myapp, version: green' causes the Service to immediately route traffic to green pods without any downtime. The Service uses the selector to dynamically discover pods with matching labels, so changing the selector seamlessly shifts traffic to the green Deployment while the blue Deployment remains untouched.

Exam trap

The trap here is that candidates think they must delete and recreate the Service to change its selector, not realizing that Kubernetes allows live updates to the selector field without downtime.

How to eliminate wrong answers

Option A is wrong because changing the blue Deployment's pod label to 'version: green' would cause both blue and green pods to have the same label, making them indistinguishable and breaking the blue-green isolation; deleting the green Deployment is unnecessary and would cause downtime. Option C is wrong because deleting and recreating the Service introduces a window where no Service exists, leading to downtime; Kubernetes allows live updates to the selector without deletion. Option D is wrong because the Service's cluster IP is a virtual IP assigned by Kubernetes and cannot be manually changed to point to specific pods; traffic routing is controlled by the selector, not the cluster IP.

Full explanation →

774

MCQmedium

A developer wants to enforce that containers in a namespace cannot run as privileged. Which Pod Security Standard profile should they apply to the namespace?

A.privileged

B.restricted

C.baseline

D.custom

AnswerC

`baseline` is the correct standard because it was designed to prevent the most well-known privilege escalations while preserving typical workload functionality. It disallows privileged containers, hostNetwork, hostPID, and hostIPC namespaces, and drops dangerous capabilities (such as CAP_SYS_ADMIN), yet still permits common capabilities like NET_BIND_SERVICE. This directly meets the developer's requirement without imposing the stricter, workload-breaking rules found in `restricted`, making it the intended middle-ground security policy.

Why this answer

(baseline) is correct because the baseline Pod Security Standard (PSS) profile enforces the minimum restrictions necessary to prevent known privilege escalations, including the prohibition of privileged containers (i.e., `privileged: true` in the security context). This profile is designed to be applied to namespaces where most workloads run, blocking the most common security issues without breaking typical applications. The restricted profile would also block privileged containers but imposes additional constraints (e.g., dropping all capabilities, read-only root filesystem) that are not required by the question's specific goal.

Exam trap

The trap here is that candidates often confuse the 'restricted' profile as the only option to block privileged containers, not realizing that 'baseline' also blocks them and is the appropriate choice when the goal is simply to prevent privileged escalation without imposing the full set of restricted constraints.

How to eliminate wrong answers

Option A is wrong because the privileged profile allows all known privilege escalations, including running containers as privileged, which is the opposite of what the developer wants to enforce. Option B is wrong because the restricted profile, while also blocking privileged containers, goes beyond the requirement by enforcing additional restrictions like dropping all capabilities, setting `runAsNonRoot: true`, and requiring a read-only root filesystem, which may break workloads that do not need such strictness. Option D is wrong because 'custom' is not a valid Pod Security Standard profile; the three standard profiles defined by Kubernetes are privileged, baseline, and restricted.

Full explanation →

775

Multi-Selectmedium

Which TWO commands can be used to create a resource from a YAML file?

Select 2 answers

A.kubectl create -f pod.yaml

B.kubectl delete -f pod.yaml

C.kubectl get -f pod.yaml

D.kubectl run -f pod.yaml

E.kubectl apply -f pod.yaml

AnswersA, E

kubectl create -f pod.yaml is correct because it directly reads the YAML manifest and sends an imperative create request to the API server. It will successfully create the Pod if no same-named Pod already exists, but it will fail with an error if the resource is already present, since it only performs creation and cannot reconcile changes. This command is ideal for one-time, explicit resource provisioning from a file.

Why this answer

The `kubectl create -f pod.yaml` command is correct because it instructs Kubernetes to create a resource (in this case, a Pod) defined in the specified YAML file. This is a declarative command that submits the resource manifest to the API server, which validates and stores it in etcd, resulting in the resource being created in the cluster.

Exam trap

The trap here is that candidates may confuse `kubectl run` (which is an imperative command for creating pods or deployments without a file) with a file-based creation command, or they may think `kubectl get` can create resources, when in fact it only retrieves them.

Full explanation →

776

MCQeasy

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

A.kubectl get events

B.kubectl logs --all-containers

C.kubectl top events

D.kubectl describe pods

AnswerA

kubectl get events retrieves all Event API objects in the current namespace (default) and prints them in a table. By default, the output is sorted by the lastTimestamp field, so the most recent events appear at the bottom. This is the standard way to inspect namespace-wide activity such as scheduling, pulling images, or failing probes.

Why this answer

`kubectl get events` retrieves all events in the current namespace (default) and displays them in a table sorted by the `LAST SEEN` timestamp by default. Events are Kubernetes API objects that record actions and state changes (e.g., pod scheduling, container restarts), making this command the standard way to observe cluster activity in a namespace.

Exam trap

The trap here is that candidates may confuse `kubectl get events` with `kubectl describe` (which shows events only for a specific resource) or assume `kubectl top` can list events because of the word 'top', but `kubectl top` is exclusively for resource usage metrics (CPU/memory).

How to eliminate wrong answers

Option B is wrong because `kubectl logs --all-containers` streams container logs from a specific pod, not cluster-wide events, and has no concept of timestamps for events. Option C is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (e.g., `kubectl top pods`), not events. Option D is wrong because `kubectl describe pods` shows detailed information about specific pods, including recent events embedded in the output, but it does not list all events in the namespace and is not sorted by timestamp.

Full explanation →

777

Multi-Selecthard

Which THREE of the following are valid fields in a NetworkPolicy spec?

Select 3 answers

A.podSelector

B.ingress

C.policyTypes

D.namespaceSelector

E.ipBlock

AnswersA, B, C

podSelector is a required field in a NetworkPolicy's spec. It uses label selector semantics to identify the pods within the current namespace to which the policy applies. An empty podSelector (e.g., `podSelector: {}`) is valid and matches all pods in the namespace, enabling default-deny policies. Without this field, the NetworkPolicy would not know which workloads its ingress or egress rules govern, so it is mandatory.

Why this answer

`podSelector` is a required field in a NetworkPolicy spec that defines which pods the policy applies to, using standard Kubernetes label selectors. It must be present to target specific pods within a namespace, and if set to an empty selector (e.g., `{}`), it selects all pods in the namespace. The CKAD exam often tests the distinction between top-level spec fields and nested rule fields, so candidates mistakenly select `namespaceSelector` or `ipBlock` as valid spec fields when they are only valid within `ingress` or `egress` rules.

Exam trap

In the CKAD exam, candidates often confuse top-level spec fields with nested rule fields, mistakenly selecting `namespaceSelector` or `ipBlock` as valid spec fields when they are only valid within `ingress` or `egress` rules.

Full explanation →

778

MCQmedium

A container in a pod is crashing repeatedly. You want to see the logs from the previous (crashed) instance of the container. Which command should you use?

A.kubectl logs --tail=10 <pod>

B.kubectl logs <pod> --previous

C.kubectl logs -c <container> <pod>

D.kubectl logs -f <pod>

AnswerB

kubectl logs <pod> --previous retrieves the logs written by the previous container instance before it terminated — exactly the data needed to diagnose a repeated crash. Kubernetes keeps a copy of the terminated container's logs on the node as long as the pod exists and the restart count is at least one, allowing --previous to replay them. The flag is the standard kubectl method to inspect the last incarnation of a failing container. This is the correct approach.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and restarted. This allows you to inspect the logs of the terminated container to diagnose the crash, even though the current container instance is running or has restarted.

Exam trap

The trap here is that candidates often confuse `--previous` with `--tail` or `-f`, thinking they need to limit output or follow logs, when the key requirement is accessing logs from a terminated container instance.

How to eliminate wrong answers

Option A is wrong because `--tail=10` only limits the output to the last 10 lines of the current container's logs, not the logs from the previous (crashed) instance. Option C is wrong because `-c <container>` specifies a container name within a multi-container pod, but does not retrieve logs from a previous crashed instance. Option D is wrong because `-f` follows (streams) the current container's logs in real time, which is irrelevant for viewing logs from a previous crash.

Full explanation →

779

MCQmedium

Which command forwards local port 8080 to port 80 of a pod named 'web-pod'?

A.kubectl port-forward service/web-service 8080:80

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

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

D.kubectl port-forward pod/web-pod 80:8080

AnswerB

This is the correct command because kubectl port-forward is given the resource type pod, the exact pod name web-pod, and the port mapping 8080:80, where the format is LOCAL_PORT:REMOTE_PORT. It opens a direct TCP tunnel from localhost:8080 on your workstation to port 80 of web-pod's IP, bypassing Services and Deployments. This ensures traffic reaches that exact pod, which is what the question specifies.

Why this answer

`kubectl port-forward` requires the resource type and name, and for a pod, the syntax is `pod/<pod-name>`. The command `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 of the pod, matching the question's requirement exactly.

Exam trap

The trap here is that candidates often confuse the port order (local:pod) or incorrectly assume that `kubectl port-forward` works with any resource type like Deployments, when in fact it only supports pods and services (and some other specific types).

How to eliminate wrong answers

Option A is wrong because it targets a Service (`service/web-service`) instead of a pod; while `kubectl port-forward` can work with services, the question specifically asks for a pod named 'web-pod', not a service. Option C is wrong because `kubectl port-forward` does not support Deployment resources directly; it only supports pods and services (and some other resource types like ReplicaSets), so targeting a Deployment will fail. Option D is wrong because it reverses the port mapping (`80:8080`), forwarding local port 80 to pod port 8080, which is the opposite of what the question requires (local 8080 to pod 80).

Full explanation →

780

MCQeasy

You need to view resource usage (CPU and memory) for all pods in the 'default' namespace. Which command should you use?

A.kubectl top pods

B.kubectl logs pods

C.kubectl describe pods

D.kubectl top nodes

AnswerA

kubectl top pods is correct because it queries the Metrics API and prints real-time CPU and memory utilization for each pod in the current namespace. This command depends on the metrics-server (or a compatible metrics provider) being deployed in the cluster; without it, kubectl top pods fails with an error. It directly surfaces the live resource usage values needed to answer the question.

Why this answer

`kubectl top pods` is the command specifically designed to display real-time CPU and memory usage metrics for pods in a Kubernetes cluster. It relies on the metrics server to collect resource usage data and presents it in a concise table format, making it the appropriate tool for viewing resource consumption in the 'default' namespace.

Exam trap

The trap here is that candidates often confuse `kubectl top pods` with `kubectl describe pods` or `kubectl logs`, mistakenly thinking that descriptive or log commands provide resource usage data, but only `kubectl top` accesses the metrics server for real-time utilization.

How to eliminate wrong answers

Option B is wrong because `kubectl logs pods` is used to retrieve log output from containers in a pod, not to view CPU or memory usage metrics. Option C is wrong because `kubectl describe pods` provides detailed metadata and status information about pods, including resource requests and limits, but does not show real-time CPU and memory usage. Option D is wrong because `kubectl top nodes` displays resource usage at the node level (aggregate CPU and memory for all pods on a node), not per-pod metrics in the 'default' namespace.

Full explanation →

781

MCQhard

Based on the exhibit, why is the container being killed and restarted?

A.The readiness probe is failing, causing the pod to be considered not ready and restarted.

B.The liveness probe is failing, causing the container to be restarted.

C.The container is running out of memory (OOM).

D.The container image is being pulled repeatedly.

AnswerB

The liveness probe is the probe that determines whether the application inside the container is healthy; if it fails, the kubelet kills the container and restarts it according to the pod's restartPolicy. The exhibit shows a restart counter increasing while the container's status cycles through Running, then terminated, then Running again, which exactly matches the behavior of a failing liveness probe. A liveness probe failure would cause the kubelet to record the reason as "Liveness probe failed: <message>" in the pod events, leading to the automatic restart observed in the exhibit.

Why this answer

In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints.

Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.

Exam trap

A common pitfall is forgetting that readiness probes do not restart containers; only liveness probes do. The restart policy (e.g., Always) acts on liveness failures.

How to eliminate wrong answers

Option B is wrong because a failing liveness probe directly causes the container to be restarted by the kubelet, but the exhibit indicates the container is being killed and restarted due to a readiness probe failure, not a liveness probe failure. Option C is wrong because an OOM kill would result in a `CrashLoopBackOff` state with an `OOMKilled` reason in the pod status, not a readiness probe failure. Option D is wrong because repeated image pulls would cause `ErrImagePull` or `ImagePullBackOff` errors, not a readiness probe failure leading to container restarts.

Full explanation →

782

MCQhard

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

A.The liveness probe is misconfigured and should use a TCP check instead.

B.The memory limit is set too low; the container is being OOMKilled during traffic spikes.

C.The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.

D.The CPU limit is too low, causing the container to be throttled and timeout.

AnswerB

The container's memory limit is 256Mi, yet during traffic spikes memory reaches roughly 250Mi plus cache overhead, which pushes usage over the cgroup limit. When that limit is breached, the kernel OOM killer terminates the container, and restartPolicy causes the observed restarts. The liveness probe is not involved because the kernel acts independently of any probe status.

Why this answer

The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Exam trap

The trap here is that candidates often confuse CPU throttling (which causes slowness and timeouts) with OOM kills (which cause restarts), and they may overlook that memory limits are a hard cap enforced by the kernel, while CPU limits are a soft cap enforced by the scheduler.

How to eliminate wrong answers

Option A is wrong because the liveness probe is already an HTTP GET check, which is appropriate for an application that exposes an HTTP endpoint; switching to a TCP check would not prevent OOM kills and would only verify the port is open, not application health. Option C is wrong because the readiness probe failing would prevent traffic from being sent to the Pod, but the Pod would not be restarted; restarts are caused by liveness probe failures or OOM kills, not readiness probe failures. Option D is wrong because CPU throttling (due to low CPU limits) causes performance degradation and timeouts, not container restarts; the kernel does not kill containers for exceeding CPU limits—it only throttles them.

Full explanation →

783

MCQhard

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

A.7

B.5

C.8

D.6

AnswerA

With maxSurge=2, the Deployment controller may temporarily create up to 2 extra pods beyond the desired replica count of 5. This means the total number of pods running simultaneously during a rolling update can reach 7. The controller enforces this ceiling to maintain availability while rolling out changes, and 7 is therefore the absolute maximum possible.

Why this answer

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

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable, mistakenly adding both to the desired replicas or thinking maxUnavailable increases the maximum running pods, when in fact maxSurge alone determines the upper limit of running pods during the update.

How to eliminate wrong answers

Option B is wrong because it assumes no surge is allowed, ignoring the maxSurge setting of 2, which permits additional pods beyond the desired replicas. Option C is wrong because it incorrectly adds both maxSurge and maxUnavailable to the desired replicas (5+2+1=8), but maxUnavailable does not increase the running pod count; it limits how many can be unavailable. Option D is wrong because it suggests a total of 6, which might come from adding only maxUnavailable (5+1=6) or misinterpreting maxSurge as 1, but the correct calculation is replicas + maxSurge = 5+2=7.

Full explanation →

784

MCQmedium

A developer has a Dockerfile that builds a Go application. The final image size is 800MB. Which improvement would MOST reduce the image size?

A.Combine all RUN commands into a single layer

B.Add a .dockerignore file to exclude unnecessary files

C.Use a smaller base image like alpine:3.19

D.Use multi-stage builds with a scratch final stage

AnswerD

Multi-stage builds are the correct approach because they allow the Dockerfile to use a full Go toolchain in a builder stage, produce the compiled binary, and then copy that artifact into a fresh scratch final stage. Scratch is an empty image with no OS, no shell, and no libraries, so all build-time dependencies, compilers, and unnecessary files are discarded, leaving only the static executable. This drastically reduces image size and attack surface, and since Go can produce statically linked binaries with CGO_ENABLED=0, the binary runs perfectly on scratch without any runtime dependencies.

Why this answer

Multi-stage builds allow copying only the binary from the build stage to a minimal base image, drastically reducing final image size.

Full explanation →

785

MCQmedium

You run the following command: 'kubectl run nginx --image=nginx --restart=Never'. What Kubernetes resource is created?

A.CronJob

B.Deployment

C.Job

D.Pod

AnswerD

When --restart=Never is specified, kubectl run creates a standalone Pod directly rather than handing the Pod to a controller. This Pod is the smallest deployable unit and has a restart policy of Never, meaning if its container exits, the kubelet will not restart it and no higher-level controller will recreate it. Therefore the resulting object is exactly a Pod.

Why this answer

The `kubectl run nginx --image=nginx --restart=Never` command creates a Pod directly, because the `--restart=Never` flag sets the restart policy to Never, which instructs Kubernetes to run the container as a standalone Pod rather than wrapping it in a higher-level controller like a Deployment or Job. The `kubectl run` command, when used without a controller flag, defaults to creating a Pod when `--restart=Never` is specified, as per the Kubernetes API behavior.

Exam trap

The trap here is that candidates often assume `kubectl run` always creates a Deployment by default, but the `--restart=Never` flag changes the behavior to create a Pod, and they may confuse the restart policy with the resource type, leading them to incorrectly select Job or Deployment.

How to eliminate wrong answers

Option A is wrong because a CronJob requires the `--schedule` flag and a restart policy of OnFailure or Never, but the command does not include a schedule, and CronJobs are for recurring tasks, not a single run. Option B is wrong because a Deployment requires a restart policy of Always (the default), but `--restart=Never` overrides this, and Deployments manage ReplicaSets for rolling updates, not a single Pod. Option C is wrong because a Job requires a restart policy of OnFailure or Never, but the command does not include the `--restart=OnFailure` flag; while `--restart=Never` can create a Job, the `kubectl run` command with `--restart=Never` and no `--job` flag creates a Pod, not a Job, as Jobs are only created when explicitly specified or when using `--restart=OnFailure`.

Full explanation →

786

MCQhard

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

A.appArmorProfile

B.seLinuxOptions

C.seccomp

D.seccompProfile

AnswerD

The seccompProfile field within the securityContext is the correct way to specify a seccomp profile. It supports three types: RuntimeDefault (the container runtime's default syscall filter), Localhost (a custom profile stored on the node), and Unconfined (no seccomp filtering). Setting this field ensures the Pod's containers run with the specified seccomp syscall restrictions.

Why this answer

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

Exam trap

The trap here is that candidates confuse the older annotation-based approach (`seccomp.security.alpha.kubernetes.io/pod`) with the newer native `seccompProfile` field, or they mistakenly think the field is simply named `seccomp` instead of `seccompProfile`.

How to eliminate wrong answers

Option A is wrong because `appArmorProfile` is not a valid field in the Kubernetes SecurityContext; AppArmor profiles are configured via annotations (e.g., `container.apparmor.security.beta.kubernetes.io`), not a dedicated field. Option B is wrong because `seLinuxOptions` is used to set SELinux labels (e.g., user, role, type, level) for a container, not to specify seccomp profiles. Option C is wrong because `seccomp` is not a field in the SecurityContext; the correct field name is `seccompProfile`, which contains the `type` and optionally `localhostProfile` subfields.

Full explanation →

787

MCQhard

An Ingress resource uses host-based routing. Which field in the Ingress YAML specifies the host header to match?

A.metadata.annotations['nginx.ingress.kubernetes.io/rewrite-target']

B.spec.rules[].host

C.spec.tls[].hosts

D.spec.rules[].http.paths[].host

AnswerB

The spec.rules[].host field is where you define a fully qualified domain name for host-based routing; the Ingress controller compares the incoming request's Host header to this value to select the appropriate path rules. This is part of the Ingress spec and is the only field that directly determines which hostname maps to which backend configuration.

Why this answer

In Kubernetes, host-based routing in an Ingress resource is configured using the `spec.rules[].host` field. This field specifies the fully qualified domain name (FQDN) that the Ingress controller should match against the `Host` header of incoming HTTP requests. When a request arrives with a matching `Host` header, the Ingress controller routes it to the backend service defined under that rule.

Exam trap

The trap here is that candidates confuse `spec.rules[].host` with `spec.tls[].hosts` or path-level host fields, mistakenly thinking TLS host configuration also controls routing, when in fact TLS hosts only specify certificate coverage and do not affect request routing.

How to eliminate wrong answers

Option A is wrong because `metadata.annotations['nginx.ingress.kubernetes.io/rewrite-target']` is an NGINX-specific annotation used to rewrite the request URI path, not to match the host header. Option C is wrong because `spec.tls[].hosts` defines the hostnames covered by a TLS certificate for HTTPS termination, not the host header matching for routing. Option D is wrong because `spec.rules[].http.paths[].host` is not a valid field; the `host` field is at the rule level, not within the path specification.

Full explanation →

788

Multi-Selectmedium

Which FOUR of the following are valid probe handlers in Kubernetes?

Select 4 answers

A.exec

B.gRPC

C.httpGet

D.tcpSocket

E.udpSocket

AnswersA, B, C, D

The `exec` handler runs a command inside the container, treating exit code 0 as success. It satisfies the stem's requirement for a valid probe handler, alongside `httpGet`, `tcpSocket` and `grpc`. This mechanism suits liveness and readiness checks needing custom logic unavailable through network or command probes alone.

Why this answer

In Kubernetes, the kubelet supports exactly four probe handler mechanisms for liveness, readiness, and startup probes. Option A (exec) is correct because it runs a command inside the container and uses the exit code to determine success. Option B (gRPC) is correct because Kubernetes supports gRPC health checking (GA since v1.24) via the gRPC Health Checking Protocol.

Option C (httpGet) is correct because it performs an HTTP GET request against the container's IP and port, treating 200-399 status codes as success. Option D (tcpSocket) is correct because it attempts a TCP connection to the specified port, succeeding if the connection is established. Option E (udpSocket) is not a valid handler, as Kubernetes does not provide a UDP-based probe type; probes use exec, httpGet, tcpSocket, or gRPC only.

Exam trap

Candidates may mistakenly think only the original three (exec, httpGet, tcpSocket) are valid, overlooking gRPC which has been supported since v1.24. Conversely, they might include udpSocket because it is a common network protocol.

Full explanation →

789

MCQeasy

A developer wants to ensure that a critical application always runs on every node in the cluster. Which resource should they use?

A.StatefulSet

B.ReplicaSet

C.Deployment

D.DaemonSet

AnswerD

DaemonSet is the correct controller because it automatically ensures a copy of the pod runs on every node in the cluster, including nodes added after the DaemonSet is created. It is designed for cluster-level daemons such as logging agents, monitoring exporters, and network proxies that need node-local presence. DaemonSet respects scheduling constraints like nodeSelectors and tolerations, but by default it provides the per-node coverage the requirement demands.

Why this answer

A DaemonSet ensures that a pod runs on every node in the cluster, or on a subset of nodes based on a node selector. This is the correct resource for deploying a critical application that must be present on all nodes, such as a logging agent or a monitoring daemon.

Exam trap

The trap here is that candidates often confuse DaemonSet with Deployment or ReplicaSet, thinking that setting a high replica count in a Deployment will achieve the same effect, but only DaemonSet guarantees a pod on every node regardless of scaling or scheduling constraints.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is designed for stateful applications that require stable network identities and persistent storage, not for running a pod on every node. Option B is wrong because a ReplicaSet ensures a specified number of pod replicas are running, but it does not guarantee placement on every node; it uses a scheduler to distribute replicas across available nodes. Option C is wrong because a Deployment manages ReplicaSets to provide declarative updates, but like a ReplicaSet, it does not enforce that a pod runs on every node; it only maintains a desired replica count.

Full explanation →

790

MCQmedium

A Job must run exactly 3 Pods in parallel. Which Job manifest field achieves this?

A..spec.activeDeadlineSeconds

B..spec.completions

C..spec.parallelism

D..spec.backoffLimit

AnswerC

The .spec.parallelism field is the correct way to control how many Pods run concurrently. Setting parallelism to 3 instructs the Job controller to launch three Pods simultaneously, ensuring the Job runs exactly three Pods in parallel. It directly defines the maximum number of active Pods at any moment, independent of the total completion count. If completions is also set, parallelism determines how many of the total completions are processed at a time.

Why this answer

`.spec.parallelism` in a Kubernetes Job manifest specifies the maximum number of Pods that should run concurrently. Setting this field to 3 ensures exactly 3 Pods run in parallel, as required by the question.

Exam trap

A common mistake in the CKAD exam is confusing `.spec.parallelism` (the number of Pods to run concurrently) with `.spec.completions` (the total number of successful Pods required to complete the Job). Candidates often select `.spec.completions` thinking it controls parallelism.

How to eliminate wrong answers

Option A is wrong because `.spec.activeDeadlineSeconds` sets a time limit for the Job's total execution duration, not the number of parallel Pods. Option B is wrong because `.spec.completions` defines the total number of successful Pod completions required for the Job to be considered complete, not the parallelism count. Option D is wrong because `.spec.backoffLimit` controls the number of retries for a failing Pod before marking the Job as failed, unrelated to parallel execution.

Full explanation →

791

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Secret as an environment variable in a pod? (Select two.)

Select 2 answers

A.envFrom: - secretRef: name: db-secret

B.volumes: - name: secret-volume secret: secretName: db-secret

C.env: - secretRef: name: db-secret

D.envFrom: - configMapRef: name: db-secret

E.env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

AnswersA, E

The `envFrom` field with `secretRef` injects all key-value pairs from the `db-secret` Secret as environment variables, each key becoming a variable name. This satisfies the stem’s requirement for exposing a Secret as an environment variable without needing individual key references, leveraging the `envFrom` mechanism for bulk injection in a Pod spec.

Why this answer

`envFrom` with a `secretRef` allows all key-value pairs from a Secret to be injected as environment variables into a container. This is a concise method to expose multiple secret entries without specifying each one individually.

Exam trap

The trap here is that candidates confuse `envFrom` with `env` syntax, or mistakenly think a volume mount (option B) or a ConfigMap reference (option D) can expose Secrets as environment variables.

Full explanation →

792

MCQeasy

Which kubectl command forwards local port 8080 to port 80 of a pod named 'web-pod'?

A.kubectl port-forward pod/web-pod 80:8080

B.kubectl expose pod web-pod --port=8080 --target-port=80

C.kubectl proxy pod/web-pod 8080:80

D.kubectl port-forward pod/web-pod 8080:80

AnswerD

This is the correct syntax: kubectl port-forward pod/web-pod 8080:80 binds your local TCP port 8080 and tunnels all traffic through the Kubernetes API server to TCP port 80 on the container in pod/web-pod. You can then access the application at http://localhost:8080. The tunnel remains active until the command is terminated, making it ideal for debugging an application that is not exposed via a Service or for accessing a specific pod directly from a workstation. This is the standard, built-in mechanism for point-to-point pod port forwarding in Kubernetes.

Why this answer

`kubectl port-forward` is the command used to forward a local port to a port on a specific pod. The syntax is `kubectl port-forward pod/<pod-name> <local-port>:<remote-port>`, so `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod'.

Exam trap

The trap here is that candidates often confuse the port order (local:remote vs remote:local) or mix up `port-forward` with `expose` or `proxy`, which serve different networking purposes in Kubernetes.

How to eliminate wrong answers

Option A is wrong because it reverses the port mapping: the syntax requires local port first, then remote port, so `80:8080` would forward local port 80 to pod port 8080, not the requested 8080 to 80. Option B is wrong because `kubectl expose` creates a Service (e.g., ClusterIP) to expose a pod or deployment, not a direct local port forward; it does not forward a local port to a pod. Option C is wrong because `kubectl proxy` creates a proxy server to the Kubernetes API server, not a port forward to a specific pod; it does not accept a pod name or port mapping in that format.

Full explanation →

793

MCQmedium

You want to enforce that all pods in a namespace have a minimum memory request of 100Mi and a maximum memory limit of 1Gi. Which resource should you create?

A.PodSecurityPolicy

B.LimitRange with limits: - max: memory: 128Mi min: memory: 100Mi

C.ResourceQuota

D.LimitRange

AnswerD

LimitRange is the correct mechanism because it applies admission-time validation and defaulting to every pod and container created in a namespace, allowing you to set minimum and maximum request and limit values. This directly enforces that all pods have a memory request within the specified range and, if configured, that a memory limit of 1Gi is not exceeded. It is the standard Kubernetes primitive for this exact use case.

Why this answer

A LimitRange (option D) is the correct resource because it allows you to set default, minimum, and maximum resource constraints (CPU/memory) at the namespace level, which are enforced per pod or container. In this case, you can define a LimitRange with a `min` of 100Mi and a `max` of 1Gi for memory, ensuring every pod in the namespace adheres to these bounds.

Exam trap

The trap here is that candidates confuse ResourceQuota (which sets namespace-wide totals) with LimitRange (which sets per-pod constraints), or they misconfigure the LimitRange with incorrect `max`/`min` values that don't match the requirement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated cluster-level resource that controls security-related pod specifications (e.g., privileged containers, host namespaces), not resource requests or limits. Option B is wrong because the `max` value of 128Mi contradicts the requirement of a maximum memory limit of 1Gi, and the `min` value of 100Mi is correct but the `max` is too restrictive; also, the syntax shown is incomplete (missing `default` and `defaultRequest` fields) and does not match the required LimitRange structure. Option C is wrong because ResourceQuota sets aggregate resource consumption limits for the entire namespace (e.g., total memory across all pods), not per-pod minimum or maximum constraints.

Full explanation →

794

MCQhard

You need to allow ingress traffic to pods with label 'app: web' from pods with label 'role: frontend' in the same namespace, and also from any pod in namespace 'monitoring'. Which NetworkPolicy egress/ingress rule correctly implements this?

A.spec: podSelector: matchLabels: app: web ingress: - from: - namespaceSelector: matchLabels: name: monitoring - podSelector: matchLabels: role: frontend

B.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend namespaceSelector: matchLabels: name: monitoring

C.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: name: monitoring

D.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - from: - namespaceSelector: matchLabels: name: monitoring

AnswerA, C

Uses separate 'from' items, so traffic from either a namespace matching 'name: monitoring' OR pods with label 'role: frontend' is allowed. However, the podSelector alone (without a namespaceSelector) matches pods in any namespace, so it allows frontend pods from all namespaces, not just the same namespace.

Why this answer

It defines two separate ingress rules: one allowing traffic from pods with label 'role: frontend' in the same namespace, and another allowing traffic from any pod in namespace 'monitoring'. In Kubernetes NetworkPolicy, when multiple items are listed under 'from' in an ingress rule, they are ORed; however, here each rule is independent, so the first rule matches pods with 'role: frontend' (no namespaceSelector, so same namespace), and the second rule matches all pods in the 'monitoring' namespace (no podSelector, so all pods). This satisfies the requirement.

Exam trap

The trap is misunderstanding how NetworkPolicy selectors combine. Within a single 'from' item, selectors are ANDed; multiple 'from' items are ORed. Option B incorrectly combines both selectors in one 'from' item (AND), requiring pods to match both conditions.

Option A and C correctly use separate 'from' items (OR), allowing frontend pods (same namespace, because a bare podSelector defaults to the namespace of the policy) or all pods from the monitoring namespace. Option D is also valid with two separate ingress rules.

How to eliminate wrong answers

Option A is wrong because it places both the podSelector and namespaceSelector in the same 'from' item, which means traffic must come from a pod that is both labeled 'role: frontend' AND in a namespace labeled 'name: monitoring' — an AND condition, not the required OR. Option B is wrong because it also combines podSelector and namespaceSelector in the same 'from' item, again requiring both conditions to be met simultaneously (AND logic), which would only allow pods with 'role: frontend' in the 'monitoring' namespace. Option D is wrong because it uses two separate 'from' blocks, but the second 'from' block has a namespaceSelector without a podSelector, which would allow traffic from any pod in 'monitoring' — however, the first 'from' block with only a podSelector would allow traffic from any pod with 'role: frontend' in any namespace (including other namespaces), which is too permissive; the requirement is to allow from pods with 'role: frontend' only in the same namespace.

Full explanation →

795

MCQhard

You have a Deployment with a liveness probe that fails intermittently, causing the pod to restart. You want to reduce the sensitivity of the probe so that it only restarts after 3 consecutive failures. Which probe parameter should you adjust?

A.initialDelaySeconds

B.periodSeconds

C.failureThreshold

D.successThreshold

AnswerC

failureThreshold is the correct parameter to adjust because it specifies the number of consecutive liveness probe failures the kubelet must observe before restarting the container. By increasing this value from its default (often 1 for liveness) to 3, you require multiple failed probes in a row, making the restart decision less sensitive to transient errors. This directly addresses the problem of a probe that fails intermittently without causing immediate container restarts.

Why this answer

The `failureThreshold` parameter defines the number of consecutive probe failures required before Kubernetes considers the probe to have failed and triggers the configured action (e.g., restarting the container). By default, this value is 3, but if it is set lower (e.g., 1), a single failure causes a restart. Increasing `failureThreshold` to 3 (or higher) ensures that the liveness probe only restarts the pod after three consecutive failures, thereby reducing sensitivity to transient issues.

Exam trap

The trap here is that candidates often confuse `failureThreshold` with `periodSeconds`, thinking that reducing the probe frequency (period) will reduce sensitivity, but the correct way to require multiple consecutive failures is to increase the `failureThreshold` value.

How to eliminate wrong answers

Option A is wrong because `initialDelaySeconds` controls how long to wait after the container starts before initiating the first probe; it does not affect the number of consecutive failures required to trigger a restart. Option B is wrong because `periodSeconds` sets the frequency (in seconds) at which the probe is executed; adjusting it changes how often checks occur, not how many failures are needed. Option D is wrong because `successThreshold` defines the number of consecutive successes required for the probe to be considered successful after a failure; it is relevant for startup and readiness probes but not for liveness probes (where it is always 1 and cannot be changed).

Full explanation →

796

Multi-Selecthard

Which THREE of the following are correct about the .dockerignore file? (Select 3)

Select 3 answers

A.It supports wildcard patterns to exclude files

B.It is a replacement for .gitignore

C.It can be used to exclude .git directory from the build context

D.It allows comments starting with #

E.It affects the files available in the running container

AnswersA, C, D

The .dockerignore file supports glob-based wildcard patterns, such as * for any sequence of characters and ? for a single character, to match files and directories within the build context. These patterns use Go's filepath.Match semantics, so * does not cross directory boundaries unless you use ** for recursive matches. This allows developers to exclude multiple files or directories with a single rule, keeping the build context lean and avoiding unnecessary data transfer to the Docker daemon.

Why this answer

The .dockerignore file supports wildcard patterns (e.g., *, ?, []) to exclude files and directories from the build context, similar to .gitignore. This allows you to define patterns like *.log or temp/* to skip unwanted files during the Docker build process.

Exam trap

The trap here is that candidates often confuse the scope of .dockerignore with runtime container files, thinking it affects the final container, when in reality it only filters the build context sent to the Docker daemon.

Full explanation →

797

MCQeasy

Which instruction in a Dockerfile sets the default command to run when the container starts, but allows overriding?

A.START

B.RUN

C.CMD

D.ENTRYPOINT

AnswerC

CMD sets the default command to execute when the container starts. It provides a default that can be easily overridden by passing a command as an argument to `docker run` (e.g., `docker run myimage echo hi` replaces the CMD). If multiple CMD instructions are present in a Dockerfile, only the last one takes effect, making it flexible for users.

Why this answer

The CMD instruction in a Dockerfile defines the default command to execute when a container starts from the image. It can be overridden by providing a command at the end of the `docker run` command, making it the correct choice for a default command that allows user override.

Exam trap

The trap here is that candidates often confuse CMD with ENTRYPOINT, thinking both are interchangeable, but CMD is designed for override while ENTRYPOINT is for a fixed command that requires `--entrypoint` to change.

How to eliminate wrong answers

Option A is wrong because START is not a valid Dockerfile instruction; Dockerfile uses instructions like CMD, ENTRYPOINT, RUN, etc. Option B is wrong because RUN executes commands during image build time, not at container startup, and its results are committed to the image layers. Option D is wrong because ENTRYPOINT sets the command that runs at container startup and is not easily overridden without the `--entrypoint` flag; it is designed for a fixed executable, not a default that can be replaced by a simple command argument.

Full explanation →

798

MCQhard

An Ingress resource has the following spec. What is the effect? spec: tls: - hosts: - myapp.example.com secretName: myapp-tls rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: myapp port: number: 80

A.Ingress terminates TLS using the secret and routes to the service.

B.Ingress uses the secret for client authentication.

C.Ingress redirects HTTP to HTTPS automatically.

D.Ingress passes the TLS connection through to the service.

AnswerA

The Ingress controller uses the certificate and private key from the referenced secret to decrypt incoming HTTPS traffic at the edge. After TLS termination, the decrypted request is forwarded as plain HTTP to the backend service identified by the ingress routing rules. This is the conventional edge-termination model for Kubernetes Ingress.

Why this answer

The Ingress spec defines TLS termination at the ingress controller using the secret `myapp-tls` for the host `myapp.example.com`. The `tls` block configures the ingress to decrypt HTTPS traffic using the certificate and key stored in that secret, and then forward the decrypted HTTP traffic to the backend service `myapp` on port 80. This is the standard behavior for securing traffic with TLS in Kubernetes Ingress.

Exam trap

The trap here is that candidates often assume TLS in an Ingress spec implies automatic HTTP-to-HTTPS redirect or TLS passthrough, but Kubernetes Ingress only terminates TLS by default unless explicitly configured otherwise.

How to eliminate wrong answers

Option B is wrong because the `tls` block in an Ingress spec is used for server-side TLS termination, not client authentication (mutual TLS). Client authentication would require additional configuration like `nginx.ingress.kubernetes.io/auth-tls-secret` or similar annotations. Option C is wrong because the spec does not include any redirect configuration; automatic HTTP-to-HTTPS redirect is not implicit and must be explicitly enabled (e.g., via annotation `nginx.ingress.kubernetes.io/ssl-redirect: "true"`).

Option D is wrong because TLS passthrough would require the `tls` block to be absent or the ingress controller to be configured for passthrough mode (e.g., with `nginx.ingress.kubernetes.io/ssl-passthrough: "true"`), and the backend would need to handle TLS itself; here the secret is used for termination, not passthrough.

Full explanation →

799

MCQmedium

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: db' in namespace 'prod'. Which YAML snippet correctly implements this?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-db namespace: prod spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 0.0.0.0/0

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: prod spec: podSelector: {} policyTypes: - Ingress ingress: - from: []

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress ingress: []

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-db namespace: prod spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: []

AnswerD

This is the correct NetworkPolicy because it selects the intended pods via podSelector.matchLabels.app: db and restricts itself to the prod namespace with the namespace field. It declares policyTypes: [Ingress] and provides an empty ingress array ([]), which means no ingress rules are defined. With no allow rules, the policy defaults to denying all ingress traffic to the selected pods, satisfying the 'deny all ingress' requirement exactly as asked.

Why this answer

It defines a NetworkPolicy that selects pods with label 'app: db' in namespace 'prod', specifies 'policyTypes: [Ingress]', and sets 'ingress: []'. An empty ingress rule list means no ingress traffic is allowed, effectively denying all ingress to the selected pods. This is the standard Kubernetes pattern for creating a deny-all ingress policy for a specific set of pods.

Exam trap

The trap here is that candidates often confuse an empty ingress array (deny-all) with an empty from array (which also denies all but is often misapplied), or they forget to set the correct podSelector and namespace, leading to policies that either allow all traffic or apply to the wrong pods.

How to eliminate wrong answers

Option A is wrong because it uses an ipBlock rule allowing traffic from 0.0.0.0/0, which permits all ingress traffic instead of denying it. Option B is wrong because it uses an empty podSelector '{}' which selects all pods in the namespace, not just those with label 'app: db', and also uses 'ingress: [from: []]' which is invalid syntax (empty from array allows no traffic but the podSelector is incorrect). Option C is wrong because it omits the namespace field (defaults to 'default'), uses an empty podSelector selecting all pods, and defines the policy without a namespace, failing to target the 'prod' namespace and the specific 'app: db' pods.

Full explanation →

800

MCQhard

A NetworkPolicy is applied to a namespace with the following rules: ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress ``` What is the effect on pods in that namespace?

A.All inbound traffic is denied, outbound traffic is allowed

B.All traffic is allowed

C.Only traffic from specific namespaces is allowed

D.All inbound and outbound traffic is denied

AnswerA

Because the policy's podSelector matches all pods and policyTypes lists only Ingress, the lack of any ingress rules creates a default deny for all inbound traffic. The policy does not include Egress in policyTypes, so no egress rule is evaluated and outbound connections remain permitted. Thus incoming requests are blocked while pods can still initiate traffic to external endpoints.

Why this answer

This NetworkPolicy selects all pods in the namespace (podSelector: {}) and specifies only Ingress in policyTypes. By default, if any NetworkPolicy selects a pod, all traffic not explicitly allowed by a rule is denied. Since no ingress rules are defined, all inbound traffic is denied.

Outbound traffic is not restricted because Egress is not listed in policyTypes and no egress rules are defined, so it remains allowed by default.

Exam trap

The CKAD exam often tests the misconception that a NetworkPolicy with no rules allows all traffic, but in reality, any NetworkPolicy selecting a pod triggers a default-deny for the specified traffic direction (Ingress or Egress) unless rules explicitly allow it.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy with an empty podSelector applies to all pods, and with no ingress rules, it denies all inbound traffic, not allows all traffic. Option C is wrong because no ingress rules are defined to allow traffic from specific namespaces; the policy only denies all inbound traffic. Option D is wrong because the policy does not include Egress in policyTypes, so outbound traffic is not affected and remains allowed by default.

Full explanation →

801

MCQmedium

A developer wants to ensure a container runs as a non-root user with user ID 1000 and group ID 2000. Which SecurityContext fields should be set?

A.runAsUser: 1000, runAsGroup: 2000, runAsNonRoot: false

B.runAsUser: 1000, runAsGroup: 2000, runAsNonRoot: true

C.runAsUser: 1000, runAsGroup: 2000, allowPrivilegeEscalation: false

D.runAsUser: 1000, fsGroup: 2000, runAsNonRoot: true

AnswerB

This is the correct setup because runAsUser: 1000 forces the container's primary process to execute with UID 1000, and runAsGroup: 2000 sets its primary GID to 2000. The runAsNonRoot: true flag performs a validation at container start, refusing to launch any container whose effective user is UID 0, even if the image's USER directive specifies root. Together these fields completely fulfill the requirement to guarantee non-root execution.

Why this answer

Setting `runAsUser: 1000` and `runAsGroup: 2000` ensures the container's processes run with user ID 1000 and group ID 2000, while `runAsNonRoot: true` enforces that the container cannot run as root (UID 0), providing a security best practice for non-root execution.

Exam trap

The trap here is confusing `fsGroup` (which controls group ownership of mounted volumes) with `runAsGroup` (which sets the container process's primary group ID), leading candidates to pick option D instead of B.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: false` explicitly allows root execution, contradicting the requirement to run as a non-root user. Option C is wrong because `allowPrivilegeEscalation: false` only prevents privilege escalation (e.g., via setuid binaries) but does not enforce a specific non-root user or group; the container could still run as root. Option D is wrong because `fsGroup: 2000` sets the group ID for volume ownership, not the container's primary group ID; the correct field for the container's group is `runAsGroup`, not `fsGroup`.

Full explanation →

802

Multi-Selecthard

Which TWO statements about Kubernetes DNS are correct?

Select 2 answers

A.The kube-dns service is responsible for DNS resolution

B.A service named 'api' in namespace 'prod' has DNS name 'api.prod.svc.cluster.local'

C.Pods with hostNetwork: true automatically get DNS entries

D.Headless services also have DNS A records for each pod

E.A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

AnswersB, D

This is correct because Kubernetes constructs a service's fully qualified domain name using the pattern `<service-name>.<namespace>.svc.<cluster-domain>`. With the default cluster domain of `cluster.local`, a service named `api` in the `prod` namespace resolves to `api.prod.svc.cluster.local`. Other pods in the cluster can rely on this DNS name for service discovery, and the name is stable for the service's lifetime.

Why this answer

Kubernetes DNS assigns a fully qualified domain name (FQDN) to services following the pattern `<service-name>.<namespace>.svc.cluster.local`. For a service named 'api' in the 'prod' namespace, the DNS name is `api.prod.svc.cluster.local`, enabling cluster-internal service discovery via CoreDNS or kube-dns.

Exam trap

A common misconception is that all pods automatically get DNS A records, but in reality, only pods with explicit `hostname` and `subdomain` fields, and belonging to a headless service, receive such entries.

Full explanation →

803

MCQhard

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

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

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

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

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

AnswerD

`kubectl create secret tls` builds a `kubernetes.io/tls` Secret directly from a PEM certificate and its matching private key, satisfying the ingress TLS requirement. The `--cert` and `--key` flags map to the `tls.crt` and `tls.key` data fields that ingress controllers expect, avoiding manual base64 encoding.

Why this answer

`kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Exam trap

The trap here is that candidates confuse the `--from-file` syntax from `kubectl create secret generic` with the dedicated TLS command, or misremember the flag names as `--certificate`/`--private-key` instead of the correct `--cert`/`--key`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret generic` creates a generic (Opaque) Secret, not a `kubernetes.io/tls` type, and Ingress requires the TLS-specific type to correctly interpret the certificate and key data. Option B is wrong because the flags `--certificate` and `--private-key` are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because `--from-file` is used with `kubectl create secret generic`, not with `kubectl create secret tls`, and the `tls.crt`/`tls.key` key names are automatically set by the `tls` subcommand when using the correct flags.

Full explanation →

804

MCQeasy

Which command streams logs from a pod in real-time?

A.kubectl logs --stream pod-name

B.kubectl logs -f pod-name

C.kubectl logs --previous pod-name

D.kubectl logs pod-name

AnswerB

The `-f` flag follows the log stream, continuously tailing new output from the container rather than printing existing entries and exiting. This satisfies the real-time streaming requirement in the stem, unlike a plain `kubectl logs pod-name` invocation, which returns the current log buffer and terminates immediately.

Why this answer

`kubectl logs -f` (the `-f` flag stands for 'follow') streams log output from a pod in real-time, similar to `tail -f` on a file. This is the standard Kubernetes command for continuous log monitoring, allowing you to see new log lines as they are written by the container.

Exam trap

CNCF often tests the `-f` flag against the non-existent `--stream` flag, exploiting the candidate's assumption that a verbose flag name exists when the actual flag is a short form.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` does not have a `--stream` flag; the correct flag for real-time streaming is `-f` (or `--follow`). Option C is wrong because `--previous` shows logs from the previous instance of a container (e.g., after a restart), not real-time streaming. Option D is wrong because `kubectl logs pod-name` without any flag only displays the current log snapshot and exits, it does not stream new log entries.

Full explanation →

805

MCQmedium

A Pod spec includes 'securityContext' with 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process inside the pod is expected to write to a mounted volume. Which securityContext field should be set to ensure the volume's group ownership is 3000?

A.supplementalGroups: [3000]

B.fsGroup: 1000

C.fsGroup: 3000

D.runAsGroup: 3000

AnswerC

fsGroup: 3000 is the correct mechanism because it simultaneously changes the group ownership of the volume's root directory to GID 3000 and adds that GID to the container's supplementary groups. With the process running as UID 1000, the group permissions on the volume now allow access via group 3000. This is exactly the Kubernetes-defined meaning of fsGroup: it alters the volume's ownership metadata to match the group that should be permitted.

Why this answer

The `fsGroup` field in the Pod's `securityContext` specifies the group ID (GID) that Kubernetes should assign to any volume mounted into the Pod. When `fsGroup: 3000` is set, Kubernetes recursively changes the ownership of the volume's files and directories to group ID 3000, and any new files created by the container process will inherit that group ownership. This ensures the container process, which runs with `runAsGroup: 3000`, can write to the volume without permission errors.

Exam trap

The trap here is that candidates often confuse `fsGroup` with `supplementalGroups` or `runAsGroup`, mistakenly thinking that setting the container's group ID alone will automatically adjust the volume's permissions, when in fact `fsGroup` is the only field that modifies the volume's ownership.

How to eliminate wrong answers

Option A is wrong because `supplementalGroups` adds additional group IDs to the container process's supplementary group list, but it does not change the ownership of the mounted volume; the volume's group ownership remains unchanged unless `fsGroup` is set. Option B is wrong because `fsGroup: 1000` would set the volume's group ownership to GID 1000, not 3000, which would not match the container's `runAsGroup: 3000` and could cause write permission issues. Option D is wrong because `runAsGroup: 3000` already sets the primary group ID for the container process, but it does not affect the ownership of the mounted volume; the volume's group ownership must be explicitly set via `fsGroup`.

Full explanation →

806

MCQmedium

A namespace 'test' has a LimitRange that sets default memory request to 256Mi and default memory limit to 512Mi. A pod in that namespace does not specify any resources. What memory request and limit will the pod get?

A.request: 0, limit: 0 (none)

B.request: 256Mi, limit: 512Mi

C.request: 512Mi, limit: 256Mi

D.request: 256Mi, limit: 256Mi

AnswerB

This is the correct outcome because the LimitRange specifies a defaultRequest of 256Mi and a defaultLimit of 512Mi. During pod admission, the controller automatically assigns these values to any container that omits memory resources. This ensures the pod has a guaranteed request of 256Mi and a hard limit of 512Mi, matching the namespace's configured defaults.

Why this answer

When a LimitRange exists in a namespace with default memory request and limit values, any pod that does not specify resource requests or limits will automatically have those defaults injected by the admission controller. This ensures the pod is subject to resource constraints even without explicit specification.

Exam trap

The trap here is that candidates might assume no resources means zero, or confuse the default request and limit values, but the LimitRange admission controller automatically injects the specified defaults.

How to eliminate wrong answers

Option A is wrong because a LimitRange with defaults means the pod will receive those defaults, not zero values. Option C is wrong because it swaps the request and limit values, which would violate the typical constraint that limit >= request. Option D is wrong because it sets both request and limit to 256Mi, ignoring the default limit of 512Mi specified in the LimitRange.

Full explanation →

807

Multi-Selecthard

Which THREE components are essential for setting up Horizontal Pod Autoscaling (HPA) based on CPU utilization? (Select three)

Select 3 answers

A.A readiness probe on the pod

B.A Service of type LoadBalancer

C.An HPA resource targeting the Deployment

D.metrics-server installed in the cluster

E.CPU resource requests set on the container

AnswersC, D, E

The HPA controller reconciles a HorizontalPodAutoscaler object against a scalable target, so the HPA resource must reference the Deployment as its scaleTargetRef. Without it, no autoscaling logic runs, regardless of metrics availability or container resource requests.

Why this answer

Option C is correct because the HPA controller scales a target workload, and in this scenario the HPA resource must be created with a scaleTargetRef pointing to the Deployment so it can adjust the replica count. Option D is correct because CPU utilization-based HPA relies on the metrics.k8s.io API provided by metrics-server; without metrics-server installed and registered, the HPA cannot retrieve pod CPU usage and will report unknown metrics. Option E is correct because HPA calculates CPU utilization as a percentage of the container's CPU request, so each container in the target pods must have resources.requests.cpu set for the utilization target to be computed.

Option A is not required because readiness probes affect traffic routing and pod availability, not the HPA's ability to read CPU metrics. Option B is not required because a LoadBalancer Service only exposes the workload externally and has no role in HPA metric collection or scaling decisions.

Full explanation →

808

MCQhard

You have a Deployment named 'frontend' with 3 replicas. You run 'kubectl rollout history deployment/frontend' and see revision 1 and revision 2. You want to rollback to revision 1. What command should you use?

A.kubectl rollout undo deployment/frontend --to-revision=1

B.kubectl set image deployment/frontend app=nginx:1.19

C.kubectl rollout undo deployment/frontend revision=1

D.kubectl rollout history deployment/frontend --revision=1

AnswerA

The command `kubectl rollout undo deployment/frontend --to-revision=1` is the correct rollback mechanism: it instructs the Deployment controller to revert the current pod template to the exact spec stored in revision 1 of its rollout history. This is the idiomatic way to undo a bad change, because it creates a new rollout (incrementing the revision number) while applying the old template, thereby preserving auditability. Using `--to-revision` explicitly targets a specific historical revision, ensuring the rollback is deterministic rather than merely undoing the most recent change.

Why this answer

The 'kubectl rollout undo' command with the --to-revision flag rolls back to a specific revision. Option A is correct.

Full explanation →

809

MCQhard

An administrator creates a Role and RoleBinding in the 'dev' namespace to allow a ServiceAccount 'sa-dev' to list Pods. Which YAML snippet correctly defines the Role?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: [""] resources: ["pods"] verbs: ["create"]

B.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: ["v1"] resources: ["pods"] verbs: ["list"]

C.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: ["apps/v1"] resources: ["pods"] verbs: ["get"]

D.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]

AnswerD

This Role correctly uses apiGroups: [""] to target the core API group, resources: ["pods"] to specify the pod resource, and verbs: ["list"] to permit listing pods in the dev namespace. Because it is a Role (not a ClusterRole) bound to the dev namespace, it grants permissions only within that namespace, which matches the requirement.

Why this answer

It uses the empty string `""` for `apiGroups`, which represents the core API group where Pods reside, and specifies the `list` verb to allow listing Pods. This matches the requirement to allow the ServiceAccount 'sa-dev' to list Pods in the 'dev' namespace.

Exam trap

The trap here is that candidates often confuse the core API group with the version string `v1` or mistakenly use `apps/v1` for Pods, and they may also confuse `list` with `get` or `create`, leading to incorrect verb selection.

How to eliminate wrong answers

Option A is wrong because it uses the verb `create` instead of `list`, which would allow creating Pods but not listing them. Option B is wrong because it incorrectly specifies `apiGroups: ["v1"]`; the core API group is represented by an empty string `""`, not `"v1"`. Option C is wrong because it uses `apiGroups: ["apps/v1"]`, which is for resources like Deployments, not Pods (Pods are in the core API group), and the verb `get` does not allow listing.

Full explanation →

810

MCQmedium

A Pod is running in a namespace with a ResourceQuota that sets 'limits.memory: 2Gi'. The pod's container spec has 'resources.limits.memory: 1Gi' and 'resources.requests.memory: 512Mi'. The pod is in 'Running' state but consumes 1.5Gi of memory. What happens?

A.The pod will be evicted by the kubelet due to namespace quota violation

B.The container will continue running because the namespace quota allows up to 2Gi

C.The container will be OOMKilled because it exceeds its own memory limit of 1Gi

D.The pod will be throttled by the kernel to stay within 1Gi

AnswerC

When a container has a memory limit of 1Gi, the kubelet configures a cgroup memory limit for that container. If the container's memory usage exceeds this limit, the kernel's OOM killer terminates the container's processes, and Kubernetes reports the reason as OOMKilled. This is a hard enforcement mechanism independent of any namespace quota or available node memory.

Why this answer

The container has a hard memory limit of 1Gi set in its resources.limits.memory. When the container's memory usage exceeds this limit (1.5Gi > 1Gi), the Linux kernel's OOM killer terminates the container process. The namespace ResourceQuota of 2Gi is not violated because the pod's limit (1Gi) is within the quota, so the kubelet does not evict the pod.

Exam trap

The trap here is that candidates confuse namespace-level ResourceQuota enforcement with container-level memory limit enforcement, assuming the quota's higher value allows the container to exceed its own limit.

How to eliminate wrong answers

Option A is wrong because the namespace quota sets a limit of 2Gi, and the pod's configured limit of 1Gi is within that quota; the kubelet only evicts pods when the total usage exceeds the quota, not when a single container exceeds its own limit. Option B is wrong because the container cannot continue running when it exceeds its own hard memory limit of 1Gi; the kernel enforces the container's limit independently of the namespace quota. Option D is wrong because memory is not throttled like CPU; exceeding a memory limit triggers an OOM kill, not throttling.

Full explanation →

811

MCQmedium

You have a Deployment with strategy type: Recreate. You update the container image. What behavior will occur during the update?

A.The update is performed in-place without pod termination.

B.New pods are created before old ones are terminated.

C.The deployment is paused automatically.

D.Old pods are terminated, then new pods are created.

AnswerD

The Recreate strategy is defined by this exact sequence: the Deployment controller first scales down all old ReplicaSets to zero, terminating every existing pod, and only then scales up the new ReplicaSet to the desired number of replicas. This ensures that no old and new versions ever run at the same time, but it also means there is a brief period of downtime. This behavior is explicitly set via `strategy.type: Recreate` in the Deployment manifest.

Why this answer

With the Recreate strategy, the Deployment controller first scales down all existing pods to zero, ensuring they are fully terminated, and then creates new pods with the updated container image. This behavior guarantees that only one version of the application runs at any time, avoiding concurrent old and new pod execution.

Exam trap

The trap here is that candidates often confuse the Recreate strategy with the RollingUpdate strategy, mistakenly thinking new pods are created before old ones are terminated, but the Recreate strategy strictly terminates all old pods first.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy does not perform in-place updates; it terminates all old pods before creating new ones. Option B is wrong because the Recreate strategy explicitly terminates old pods before creating new ones, unlike the RollingUpdate strategy which creates new pods before terminating old ones. Option C is wrong because the Recreate strategy does not pause the Deployment; it proceeds with the termination and creation cycle automatically.

Full explanation →

812

MCQeasy

A Secret of type kubernetes.io/tls requires two data keys. What are they?

A.ca.crt and tls.key

B.certificate and key

C.cert.crt and cert.key

D.tls.crt and tls.key

AnswerD

According to the Kubernetes documentation for TLS secrets, the type kubernetes.io/tls requires exactly two data keys: tls.crt, which contains the PEM-encoded public certificate (or certificate chain), and tls.key, which contains the PEM-encoded private key. These keys are the standard interface that ingress controllers, kubelet, and other components rely on to configure TLS termination. Creating a secret with these keys ensures it is immediately usable for securing applications.

Why this answer

Kubernetes requires that a Secret of type `kubernetes.io/tls` contain exactly two data keys: `tls.crt` for the TLS certificate and `tls.key` for the private key. This is mandated by the Kubernetes API specification for TLS secrets, which are used to secure ingress and other TLS-terminated endpoints.

Exam trap

The trap here is that candidates often confuse the required key names with common file extensions or generic terms like `certificate` and `key`, but Kubernetes enforces the exact keys `tls.crt` and `tls.key` for TLS secrets.

How to eliminate wrong answers

Option A is wrong because `ca.crt` is an optional key for a CA certificate, not a required key for a TLS secret; the required keys are `tls.crt` and `tls.key`. Option B is wrong because `certificate` and `key` are generic names that do not match the exact key names (`tls.crt` and `tls.key`) required by the Kubernetes API for TLS secrets. Option C is wrong because `cert.crt` and `cert.key` are not the standard key names; Kubernetes specifically expects `tls.crt` and `tls.key` as defined in the Secret type `kubernetes.io/tls`.

Full explanation →

813

MCQhard

An Ingress resource is defined as: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 tls: - hosts: - example.com secretName: tls-secret What must exist in the cluster for TLS termination to work?

A.An IngressClass annotation specifying the ingress controller

B.A ServiceAccount named tls-secret

C.A Secret named tls-secret of type kubernetes.io/tls in the same namespace

D.A ConfigMap named tls-secret with certificate data

AnswerC

The Ingress resource must reference a Secret of type kubernetes.io/tls in its spec.tls[].secretName field, and Kubernetes requires that Secret to exist in the same namespace as the Ingress. This Secret must contain the keys tls.crt and tls.key, holding the PEM-encoded certificate and private key. The ingress controller reads those exact keys to terminate HTTPS traffic, so creating this Secret in the correct namespace is the essential prerequisite for TLS to function.

Why this answer

C is correct because TLS termination requires the actual TLS certificate and key to be stored in a Kubernetes Secret of type `kubernetes.io/tls`. The Ingress controller reads this Secret to terminate HTTPS connections, decrypting traffic before forwarding it to the backend service. Without this Secret, the Ingress controller cannot present a valid certificate to clients.

Exam trap

The trap here is that candidates may think TLS termination requires an IngressClass annotation or a ConfigMap, but the CKAD exam specifically tests that a Secret of type `kubernetes.io/tls` with the correct name and namespace is mandatory for TLS to work.

How to eliminate wrong answers

Option A is wrong because an IngressClass annotation is not required for TLS termination; it is used to specify which Ingress controller should process the Ingress, but TLS termination works as long as any Ingress controller is present. Option B is wrong because a ServiceAccount is unrelated to TLS certificates; it is used for pod identity and RBAC, not for storing TLS material. Option D is wrong because a ConfigMap cannot hold sensitive certificate data; Secrets are designed for confidential data like TLS keys, and ConfigMaps are for non-sensitive configuration.

Full explanation →

814

Multi-Selectmedium

Which TWO of the following are valid ways to consume a Secret named 'db-secret' in a Pod? (Choose two.)

Select 2 answers

A.As environment variables using env with valueFrom.configMapKeyRef

B.As environment variables using envFrom with secretRef

C.As a command-line argument using $(DB_PASSWORD)

D.As files mounted via a volume with secret.secretName

E.As an imagePullSecrets entry

AnswersB, D

A container can consume a Secret in its entirety by using envFrom with a secretRef in the container's environment specification. Kubernetes enumerates every key in the referenced Secret and creates an environment variable for each, provided the key is a valid environment variable name. This is one of the two officially supported ways to inject Secret data into a running container.

Why this answer

`envFrom` with `secretRef` allows a Pod to consume all key-value pairs from a Secret named 'db-secret' as environment variables. This is a standard Kubernetes feature for injecting Secret data into containers without needing to specify each key individually.

Exam trap

CNCF often tests the distinction between `configMapKeyRef` and `secretKeyRef` — candidates mistakenly use `configMapKeyRef` for Secrets because both are key-value stores, but Secrets require `secretKeyRef` for individual key injection.

Full explanation →

815

MCQmedium

You have a pod that is stuck in 'Pending' state. Which command would you run first to diagnose the issue?

A.kubectl logs <pod>

B.kubectl get pods

C.kubectl get events

D.kubectl describe pod <pod>

AnswerD

kubectl describe pod <pod> is the standard diagnostic for a Pending pod because it shows the pod's Conditions (PodScheduled, Initialized, ContainersReady) and a dedicated Events section containing the exact scheduler or kubelet warnings. For example, it will display FailedScheduling with node resource pressure, FailedMount for volume issues, or taint/toleration mismatches. This output, combined with the assigned node and container statuses, directly pinpoints the blocker so you can take corrective action.

Why this answer

`kubectl describe pod <pod>` provides detailed information about the pod's current state, including events, conditions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims pending). This is the first diagnostic step for a 'Pending' pod, as it surfaces the root cause (e.g., node resource pressure, PVC binding failures) without requiring additional commands.

Exam trap

The trap here is that candidates often jump to `kubectl logs` (Option A) thinking it shows startup errors, but logs are only available after containers start, making it useless for a 'Pending' pod; instead, `kubectl describe pod` is the standard first diagnostic tool for scheduling and resource issues.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod>` retrieves container logs, which are only available if the pod has started running; a 'Pending' pod has not yet scheduled or started containers, so logs are empty or inaccessible. Option B is wrong because `kubectl get pods` only shows the pod's status (e.g., 'Pending') and basic metadata, not the underlying reasons for the pending state (e.g., unschedulable, image pull errors). Option C is wrong because `kubectl get events` lists cluster-wide events, which may include relevant scheduling failures, but it is less targeted than `kubectl describe pod`, which filters events specific to the pod and presents them alongside other critical details like node selector mismatches or taint tolerations.

Full explanation →

816

MCQhard

An ingress resource is created with the following spec. Which request will be routed to the 'green' service? ```yaml spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: blue port: number: 80 - path: /api/v1 pathType: Exact backend: service: name: green port: number: 80 ```

A.http://example.com/api/v1

B.http://example.com/api/v1/

C.http://example.com/api

D.http://example.com/

AnswerA

This request URL has the path /api/v1 with no trailing slash, which exactly matches the ingress rule's pathType: Exact specification for /api/v1. In Kubernetes, an Exact path rule requires a case-sensitive, byte-for-byte match of the entire request path. Therefore, this request is unambiguously routed to the green backend service.

Why this answer

The request to http://example.com/api/v1 matches the Exact path /api/v1, which routes to the green service. In Kubernetes ingress, Exact pathType requires the request path to be identical to the specified path, and /api/v1 matches exactly.

Exam trap

The trap here is that candidates often forget that Exact pathType requires an exact match without a trailing slash, leading them to choose Option B with the trailing slash, or they confuse Prefix and Exact matching, thinking /api/v1 would match the Prefix /api instead of the Exact /api/v1.

How to eliminate wrong answers

Option B is wrong because the request path /api/v1/ includes a trailing slash, which does not match the Exact path /api/v1 (without trailing slash), so it will not be routed to the green service. Option C is wrong because /api matches the Prefix path /api, which routes to the blue service, not green. Option D is wrong because / matches no defined path, so it will not be routed to any service (default behavior is 404).

Full explanation →

817

Drag & Dropmedium

Order the steps to update a Kubernetes Secret and ensure a Pod uses the new secret.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Update secret, then if mounted as volume, Pod picks it up automatically; if env, need restart.

Full explanation →

818

Multi-Selectmedium

Which THREE are valid ways to expose a canary deployment for testing? (Select three)

Select 3 answers

A.Create a separate Service for the canary with a different selector and provide its endpoint to testers.

B.Use an Ingress with traffic splitting via annotations (e.g., nginx.ingress.kubernetes.io/canary).

C.Use a DaemonSet instead of Deployment for canary.

D.Use a NetworkPolicy to restrict canary pods from receiving traffic.

E.Use a single Service that selects both stable and canary pods based on a common label.

AnswersA, B, E

You can expose canary pods by creating a dedicated Service whose selector matches only the canary version label—e.g., version=canary. This Service gets its own stable ClusterIP (or LoadBalancer) and routes exclusively to canary pods, providing a direct endpoint for testers, QA teams, or automated verification pipelines. This approach is valid because it gives controlled access to the canary without mixing it into the production traffic path, but it does not automatically shift user traffic—it is for manual or targeted testing.

Why this answer

Option A is correct because creating a dedicated Service whose selector matches only the canary pods' labels gives testers a stable, isolated endpoint (ClusterIP/NodePort/LoadBalancer) that routes exclusively to the canary, without touching production traffic. Option B is correct because an Ingress controller such as NGINX supports canary annotations (e.g., nginx.ingress.kubernetes.io/canary: "true", canary-weight, canary-by-header, canary-by-cookie) to split or conditionally route a percentage or specific requests to the canary backend. Option E is correct because a single Service selecting both stable and canary pods via a shared common label will load-balance across all matching endpoints, which is a simple way to expose the canary alongside stable for testing (albeit without fine-grained control).

Option C is not valid because a DaemonSet schedules one pod per node for node-level agents, not for canary traffic exposure. Option D is not valid because a NetworkPolicy only filters pod ingress/egress traffic; it restricts rather than exposes the canary and provides no routing mechanism to testers.

Exam trap

CKAD often tests the misconception that DaemonSets or NetworkPolicies can be used for canary exposure, when in reality canary testing depends on Service selectors, Ingress annotations, or shared-label Services.

Full explanation →

819

MCQeasy

You need to view the logs of a container named 'sidecar' inside a pod named 'app'. Which command should you use?

A.kubectl logs app -c sidecar

B.kubectl logs app --previous -c sidecar

C.kubectl logs app sidecar

D.kubectl logs app -c sidecar -p

AnswerA

The command `kubectl logs app -c sidecar` is correct because it explicitly targets the `sidecar` container within the `app` pod using the `-c` flag. This is the required syntax for retrieving logs from a specific container in a multi-container pod. Without the `-c` flag, kubectl would either fail or default to the first container, so this option precisely fetches the current logs of the desired container.

Why this answer

`kubectl logs app -c sidecar` explicitly targets the 'sidecar' container within the 'app' pod. In Kubernetes, when a pod runs multiple containers, you must use the `-c` flag to specify which container's logs to retrieve; otherwise, the command fails or returns ambiguous output.

Exam trap

The trap here is that candidates often forget the `-c` flag for multi-container pods and assume the container name can be passed as a positional argument, leading them to choose option C.

How to eliminate wrong answers

Option B is wrong because `--previous` retrieves logs from the previous instance of a terminated container, not from the currently running 'sidecar' container, and is unnecessary for viewing live logs. Option C is wrong because `kubectl logs app sidecar` treats 'sidecar' as a pod name, not a container name, leading to an error or incorrect log retrieval. Option D is wrong because `-p` is a shorthand for `--previous`, which again fetches logs from a terminated container, not the current 'sidecar' container.

Full explanation →

820

MCQmedium

You need to create a Secret of type kubernetes.io/tls for use with an Ingress. Which kubectl command should you use?

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

B.kubectl create secret docker-registry my-tls --docker-username=user --docker-password=pass

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

D.kubectl create secret tls my-tls --from-file=tls.crt --from-file=tls.key

AnswerA

This command correctly creates a Secret with type kubernetes.io/tls by using the dedicated --cert and --key flags. kubectl reads the PEM-encoded certificate and private key, stores them under the canonical data keys tls.crt and tls.key, and sets the type so Ingress resources can consume it for TLS termination. No other command form produces a TLS-typed Secret with both required data fields.

Why this answer

`kubectl create secret tls` is the dedicated command for creating a TLS secret, which automatically stores the certificate and key under the expected keys `tls.crt` and `tls.key` respectively. This secret type (`kubernetes.io/tls`) is required by Ingress controllers to serve HTTPS traffic, and the command directly accepts `--cert` and `--key` flags for the PEM-encoded files.

Exam trap

The trap here is that candidates confuse the `--from-file` pattern (used with `generic` secrets) with the `tls` subcommand, or mistakenly think any secret containing a cert and key will work for Ingress, when in fact the secret must be of type `kubernetes.io/tls` with the exact keys `tls.crt` and `tls.key`.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret docker-registry` creates a secret of type `kubernetes.io/dockerconfigjson` for container registry authentication, not for TLS certificates. Option C is wrong because `kubectl create secret generic` creates a generic Opaque secret, which stores files as arbitrary keys (e.g., `cert.pem` and `key.pem`) but does not set the required `tls.crt` and `tls.key` keys, and the type will not be `kubernetes.io/tls`, so Ingress will not recognize it. Option D is wrong because `kubectl create secret tls` does not accept `--from-file` flags; it requires the `--cert` and `--key` flags to correctly populate the secret's data fields.

Full explanation →

821

Multi-Selectmedium

Which TWO statements about Services are true? (Choose two.)

Select 2 answers

A.A Service of type LoadBalancer automatically creates a NodePort Service.

B.A Service of type ClusterIP is accessible from outside the cluster.

C.A Service of type ExternalName requires a selector to route traffic.

D.A headless Service has clusterIP set to "0.0.0.0".

E.A Service of type NodePort exposes the Service on a static port on each Node's IP.

AnswersA, E

A Service of type LoadBalancer is an extension of NodePort: the cloud provider provisions a load balancer that targets the NodePort Service automatically created for that Service. Because NodePort exposes the Service on every node's IP and port, the external load balancer can route incoming traffic to any healthy node, which then forwards it through the ClusterIP to the selected pods. Thus, you only need to define a single LoadBalancer Service and Kubernetes creates the underlying NodePort and ClusterIP Services for you.

Why this answer

When a Service of type LoadBalancer is created, Kubernetes automatically creates a corresponding NodePort Service (and a ClusterIP Service) as part of its implementation. The cloud load balancer routes external traffic to the NodePort on each node, which then forwards to the ClusterIP. This is defined in the Kubernetes Service specification and is a core behavior of the LoadBalancer type.

Exam trap

The CKAD exam often tests the misconception that a LoadBalancer Service is a standalone type, when in fact it is built on top of NodePort and ClusterIP, and candidates may forget that ExternalName Services do not require selectors.

Full explanation →

822

MCQmedium

A Service of type NodePort is created with 'spec.ports[0].nodePort: 30080'. The cluster nodes have IPs 10.0.0.1, 10.0.0.2. Which command can be used to test connectivity to the Service from outside the cluster?

A.curl 10.0.0.1:30080

B.curl 10.0.0.1:80 --header 'Host: service.namespace.svc.cluster.local'

C.curl 10.0.0.1:80

D.curl 10.96.0.1:30080

AnswerA

This is correct because NodePort services are published on the port specified in `spec.ports[0].nodePort` (30080) on every node's IP address. Since 10.0.0.1 is a node IP, traffic sent to that address on port 30080 is intercepted by kube-proxy and forwarded to the backing pods, regardless of which node actually runs the pod.

Why this answer

A NodePort service exposes the same port (nodePort: 30080) on every cluster node's IP address. From outside the cluster, you can reach the service by targeting any node's IP and the nodePort, so `curl 10.0.0.1:30080` will connect to the service via node 10.0.0.1.

Exam trap

The trap here is that candidates often confuse the clusterIP port (80) with the nodePort (30080), or assume that the clusterIP (e.g., 10.96.0.1) is reachable from outside the cluster, when in fact it is only routable within the cluster network.

How to eliminate wrong answers

Option B is wrong because it uses port 80 (the clusterIP port, not the nodePort) and adds a Host header, which is unnecessary for NodePort access; the service is not listening on port 80 on the node's external interface. Option C is wrong because it uses port 80 on the node IP, but the NodePort service only listens on the configured nodePort (30080), not on the targetPort or clusterIP port. Option D is wrong because 10.96.0.1 is a typical clusterIP address (e.g., for the Kubernetes API server), not the service's clusterIP, and even if it were the service's clusterIP, that IP is only reachable from inside the cluster, not from outside.

Full explanation →

823

Multi-Selectmedium

Which TWO statements about labels and selectors are correct? (Select TWO.)

Select 2 answers

A.Services use selectors to determine which pods receive traffic.

B.Labels are key-value pairs that can be attached to Kubernetes objects.

C.Selectors are used to identify a single object based on its labels.

D.Selectors must be defined in the resource definition itself.

E.Labels cannot be added after an object is created.

AnswersA, B

Correct. A Service's spec.selector is an equality-based label selector. When you create a Service, its selector matches Pods that carry the specified labels, and the Service's Endpoints object is populated with those Pods, enabling traffic distribution. The selector must exactly match the labels on the Pod template at creation time.

Why this answer

A is correct because Services use label selectors in their spec.selector field to determine which Pods receive traffic. B is correct because labels are key-value pairs that can be attached to Kubernetes objects for identification and grouping. C is incorrect because selectors return a set of objects matching the given labels, not a single object.

D is false because selectors are not required to be defined in the resource definition itself; they are used in controllers and Services to select objects. E is false because labels can be added or modified after creation.

Exam trap

The trap here is that candidates may confuse selectors as a required field in the object definition itself (like a label), when in fact selectors are a query mechanism defined in controllers or Services to match labels on other objects, and labels can be modified at any time after creation.

Full explanation →

824

MCQhard

You are performing a canary deployment using two Deployments: 'app-stable' (replicas: 9) and 'app-canary' (replicas: 1), both with label 'app: myapp'. A Service selects pods with 'app: myapp' and 'version: stable'. How can you route traffic to the canary?

A.Update the canary Deployment's image to a different version.

B.Change the Service's selector to 'version: canary'.

C.Add label 'version: stable' to the canary Deployment's pod template, so both Deployments have the same label, and keep the Service selector as is.

D.Add label 'version: canary' to the canary Deployment's template and update the Service selector to 'version: stable || version: canary'.

AnswerC

Adding the label 'version: stable' to the canary Deployment's pod template ensures that its pods are selected by the existing Service selector (which is already set to 'version: stable'). The Service then load-balances across all matching pods from both Deployments, distributing traffic proportionally to their replica counts. For example, with 9 stable and 1 canary pod, the canary receives about 10% of traffic, enabling controlled rollout while both versions share the same label and the Service selector remains unchanged.

Why this answer

Adding the label 'version: stable' to the canary Deployment's pod template makes its pods match the Service's selector ('app: myapp' and 'version: stable'). This allows the Service to include both stable and canary pods, distributing traffic according to the replica ratio (9:1). The canary image can be different from stable, but the label ensures the Service routes traffic to both sets of pods.

Exam trap

The trap here is that candidates think they must change the Service's selector to include the canary, but the correct approach is to make the canary pods match the existing selector by adding the required labels, keeping the Service unchanged.

How to eliminate wrong answers

Option A is wrong because changing the canary's image does not affect the Service's selector; without matching labels, the canary pods remain unselected and receive no traffic. Option B is wrong because changing the Service's selector to 'version: canary' would exclude the stable pods, breaking the canary deployment pattern and routing all traffic to the single canary pod. Option D is wrong because Kubernetes selectors do not support logical OR operators (like '||'); selectors are based on equality or set-based matching (e.g., 'In'), and the proposed syntax is invalid, so the Service would fail to select any pods.

Full explanation →

825

MCQhard

You have a pod that needs to mount a Secret as a volume. The Secret has keys 'username' and 'password'. How should the volumes and volumeMounts be configured to mount the secret at /etc/secret with each key as a file?

A.volumes: - name: secret-vol hostPath: path: /etc/secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

B.volumes: - name: secret-vol configMap: name: my-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

C.volumes: - name: secret-vol emptyDir: {} containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

D.volumes: - name: secret-vol secret: secretName: my-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

AnswerD

This is the idiomatic Kubernetes approach: the secret volume source references a Secret object by name, and kubelet populates the volume with files named after the Secret's keys and containing their values. When mounted at /etc/secret, each key becomes a file in that directory, and the container can read them securely. The volume is backed by tmpfs (in-memory) to avoid writing sensitive data to disk, and the Secret's data is automatically injected without manual steps.

Why this answer

It uses the `secret` volume type with `secretName: my-secret`, which mounts the specified Kubernetes Secret as a volume. When mounted at `/etc/secret`, each key in the Secret (e.g., 'username' and 'password') becomes a file in that directory, with the file name matching the key and the file content being the decoded value of the key. This is the standard method for exposing Secret data as files in a pod.

Exam trap

The trap here is that candidates may confuse the `secret` volume type with `configMap` (Option B) or incorrectly assume that `hostPath` (Option A) can be used to reference a Secret, when in fact only the `secret` volume type with the correct `secretName` field will mount the Secret's keys as files.

How to eliminate wrong answers

Option A is wrong because `hostPath` mounts a directory from the host node's filesystem, not a Kubernetes Secret; it does not provide the Secret's key-value pairs as files. Option B is wrong because `configMap` is used for ConfigMaps, not Secrets; while the syntax is similar, Secrets require the `secret` volume type to properly handle base64-encoded data and access control. Option C is wrong because `emptyDir` creates an empty temporary directory that is shared between containers; it does not inject any Secret data into the pod.

Full explanation →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 751–825