Certified Kubernetes Application Developer CKAD CKAD Questions 151–160 | Page 3/3

151

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 log output in real-time.

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 →

152

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 →

153

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 defines the scaling policy.

Why this answer

HPA requires metrics-server to collect CPU metrics, CPU resource requests set on containers so HPA can calculate utilization, and the HPA resource itself targeting the Deployment. Therefore, options C, D, and E are correct.

Full explanation →

154

MCQmedium

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

A.Delete the namespace and redeploy all workloads

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

C.Increase the CPU request for the container

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

AnswerD

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container more memory to operate without being killed by the Out-of-Memory (OOM) killer.

Exam trap

The trap here is that candidates may confuse 'OOMKilled' with a general crash and think restarting the pod (Option B) will fix it, but the OOM killer will immediately terminate the new container again because the memory limit remains unchanged.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not address the root cause (insufficient memory limit) and would cause unnecessary downtime. Option B is wrong because deleting and recreating the pod will only temporarily restart the container; it will still hit the same memory limit and crash again, resulting in the same CrashLoopBackOff state. Option C is wrong because increasing the CPU request does not affect memory constraints; OOMKilled is a memory-related issue, not CPU-related.

Full explanation →

155

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 →

156

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 →

157

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 →

158

MCQeasy

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

A.The service selector does not match any pods

B.The service port is already in use

C.The cluster does not have a load balancer controller

D.The namespace has a NetworkPolicy blocking traffic

AnswerC

Without a load balancer controller running in the cluster, there is no controller-manager component to detect the LoadBalancer service and create the actual load balancer resource in the cloud provider. Consequently, the service's status field for load balancer ingress remains unset and the external IP stays stuck at '<pending>' indefinitely. This is the standard symptom when a cluster is misconfigured or running on bare metal without a controller like MetalLB.

Why this answer

A Service of type LoadBalancer in Kubernetes requires an external load balancer controller (e.g., cloud-controller-manager for AWS, Azure, GCP, or MetalLB for on-premises) to provision and assign the external IP. If no such controller is running in the cluster, the external IP remains in 'pending' state indefinitely because Kubernetes itself does not implement load balancer logic. This is the most common reason for a stuck pending external IP.

Exam trap

A common pitfall in CKAD is assuming that a Service of type LoadBalancer will automatically get an external IP in any Kubernetes cluster. In reality, Kubernetes relies on an external load balancer controller (e.g., cloud-controller-manager or a bare-metal solution like MetalLB) to provision the IP. Without such a controller, the external IP remains pending.

How to eliminate wrong answers

Option A is wrong because a mismatched selector would cause the Service to have no endpoints, but the external IP would still be assigned by the load balancer controller once it provisions the IP; the pending state is unrelated to endpoint availability. Option B is wrong because port conflicts on the node (e.g., hostPort) would cause the Service to fail to start or report errors, not leave the external IP pending; the load balancer controller does not check node port availability before assigning the IP. Option D is wrong because NetworkPolicies restrict traffic flow at the pod level (Layer 3/4) and do not affect the provisioning of the external IP by the load balancer controller; the IP would still be assigned even if traffic is later blocked.

Full explanation →

159

Multi-Selecthard

Which THREE of the following are valid fields in a LimitRange resource to enforce resource constraints at the container level? (Choose three.)

Select 3 answers

A.min

B.defaultRequest

C.default

D.maxLimitRequestRatio

AnswersA, B, D

Correct. `min` specifies the minimum amount of resources a container can request or consume.

Why this answer

The three valid fields in a LimitRange resource that enforce resource constraints at the container level are `min`, `defaultRequest`, and `maxLimitRequestRatio`. `min` sets the minimum resource request or limit per container. `defaultRequest` sets the default resource request if not specified, ensuring a minimum request is applied. `maxLimitRequestRatio` enforces a maximum ratio between limit and request, constraining the relationship. While `default` is a valid field, it sets a default limit rather than enforcing a constraint directly, so it is not among the three asked.

Exam trap

Candidates often think `default` is one of the three because it is commonly used, but it only sets a default limit, not a hard constraint like `min`, `defaultRequest`, or `maxLimitRequestRatio`.

Full explanation →

160

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 →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 151–160