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

A is correct because a TCP liveness probe only checks if the port is open and accepting connections, not whether the application is actually processing requests. If the application is listening on port 8080 but is stuck or not handling HTTP traffic correctly, the TCP probe will still succeed, and Kubernetes will not restart the container. This is a common scenario where the application is 'alive' at the socket level but not 'healthy' at the application layer.

The maxUnavailable field in the rolling update strategy specifies the maximum number of pods that can be unavailable during the update. Setting it to 2 ensures at most 2 pods are unavailable.

Init containers must run successfully (exit 0) before the main containers start. If an init container fails, Kubernetes restarts it (if restartPolicy is Always or OnFailure) until it succeeds. The pod will remain in Init:Error state until the init container succeeds.

The message indicates multiple issues: taints and node affinity. The pod cannot be scheduled due to taints not being tolerated AND node affinity not matching.

Blue-green deployment involves running two versions (blue and green) and switching traffic by updating the Service's selector.

Istio uses sidecar proxies (Envoy) injected into pods to manage traffic, enforce policies, and collect telemetry. It does not replace kube-proxy but works alongside it.

The correct command uses 'kubectl expose' with the appropriate flags to create a ClusterIP service targeting port 8080 and selecting pods with label 'app=web'.

The 'kubectl scale' command is used to change the number of replicas of a Deployment, ReplicaSet, or StatefulSet.

.dockerignore files exclude files from the build context, improving build performance and security by preventing unwanted files from being copied into the image.

Option A is correct because the `envFrom` field in a pod spec can reference a Secret using `secretRef`, and the optional `prefix` field prepends a string to each key from the Secret when exposing them as environment variables. This allows all key-value pairs from the Secret to be injected as environment variables with a common prefix, which is a concise and valid method.

Option C is correct because the `env.valueFrom.secretKeyRef` field in a Pod spec is the proper mechanism to inject a specific key from a Kubernetes Secret as an environment variable. The `name` field identifies the Secret (`db-secret`), and the `key` field specifies which key within that Secret (`url`) to use. This is defined in the Kubernetes API for exposing Secret data as environment variables.

An empty podSelector selects all pods. With no rules, both ingress and egress traffic are denied by default.

Option D is correct because in Kubernetes, CPU requests are specified in millicores (e.g., 250m) and memory limits use binary units like Mi (Mebibytes). The value '250m' equals 0.25 CPU cores, and '512Mi' is 512 Mebibytes (512 * 1024^2 bytes), which is the standard unit for memory limits.

Option D is correct because the readiness probe passes immediately (since /ready returns 200), so the Pod is marked Ready and added to the Service. However, the liveness probe fails initially (since /health returns non-200 for the first 30 seconds), causing the kubelet to restart the container repeatedly until the liveness probe starts succeeding after 30 seconds. This behavior is defined by Kubernetes: a failing liveness probe triggers container restarts, while a failing readiness probe only removes the Pod from Service endpoints.

The Pod Security Admission (PSA) restricted profile requires that pods drop all capabilities, set `runAsNonRoot: true`, set `seccompProfile.type` to `RuntimeDefault` or `Localhost`, set `allowPrivilegeEscalation: false`, and restrict `runAsUser` to a non-root user (which is satisfied by `runAsUser: 1000`). The provided pod meets all these requirements, so it will be admitted. The `runAsUser` field is allowed as long as the user ID is not 0 (root), and the `seccompProfile.type` is correctly set to `RuntimeDefault`, which is one of the permitted values.

Option B is correct because `env.valueFrom.configMapKeyRef` allows you to inject a specific key from a ConfigMap as an environment variable into a container. This is a standard Kubernetes API pattern for selective key injection, where you reference the ConfigMap name and the desired key, and the value is set at pod creation time.

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

Option D is correct because `terminationGracePeriodSeconds` defines the time Kubernetes waits for a pod to shut down gracefully after sending a SIGTERM signal. Setting it to 30 seconds gives the application the required cleanup window before a SIGKILL is forced.

The 'replicas' field sets the desired number of pods. Option A is correct.

Option D is correct because the container is failing, and the most direct way to determine why is to inspect its stdout/stderr logs using 'kubectl logs backend'. This command retrieves the container's log output, which typically contains error messages, stack traces, or application-level failure reasons. In CKAD scenarios, when a pod is in CrashLoopBackOff or Error state, logs are the first diagnostic step to identify the root cause.

With the Recreate strategy, all existing pods are killed before new ones are created. This can cause downtime.

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

NetworkPolicy is a namespaced resource, and if no policies select a pod, it allows all traffic by default.

In an Ingress rule, the 'host' field specifies the hostname for routing.

Option D is correct because `timeoutSeconds` defines the maximum time a probe waits for a response before considering the probe failed. Option E is correct because `initialDelaySeconds` configures the delay before the probe starts after the container starts, allowing the application to initialize. Both are standard fields in the Kubernetes probe specification (liveness, readiness, startup).

helm list lists all releases in the current namespace. Option B is correct.

The ingress 'from' rule uses podSelector to select source pods within the namespace. Option D uses namespaceSelector, which selects namespaces, not pods.

Option C is correct because when a container's securityContext specifies both `capabilities.drop: ['ALL']` and `capabilities.add: ['NET_ADMIN']`, the `drop: ['ALL']` first removes all capabilities, and then `add: ['NET_ADMIN']` adds back only the NET_ADMIN capability. The final effective set is exactly `[NET_ADMIN]`. This is the intended Kubernetes behavior: `drop` is processed before `add` within the same container spec.

Option A is correct because the `volumes` field in a Pod spec allows you to define a volume of type `secret`, which can then be mounted into a container using the `volumeMounts` field. This is the standard Kubernetes mechanism for exposing Secret data as files in the container's filesystem.

Blue-green deployments require two Deployments (one for blue, one for green) and a Service that switches selector labels to point to the active deployment. Option C is correct.

Endpoints only include ready pods. One pod may not be passing readiness probes.

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

NodePort services expose a port on each node's IP address, allowing external access. Option B is correct.

The 'kubectl get endpoints' command shows the endpoints (pods) that a Service is routing to. The shorthand is 'ep'.

Option D is correct because `kubectl get endpoints server` directly retrieves the Endpoints object associated with the service named 'server'. Endpoints are automatically managed by Kubernetes and list the IP addresses and ports of pods that match the service's selector. If the endpoints list is empty, it indicates that no pods are matching the service's selector, which is a common cause of connectivity issues.

kubectl apply creates or updates resources using declarative configuration, preserving changes made by others. kubectl replace replaces the existing resource with the provided spec, which can overwrite fields not managed by the user. Option C correctly describes this.

A Readiness probe (Option A) is specifically designed to determine whether a pod is ready to serve traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring traffic is only sent to pods that are ready. This directly fulfills the requirement of controlling traffic routing based on pod readiness.

The correct command is 'kubectl port-forward pod/db-pod 15432:5432'. This forwards local port 15432 to the pod's port 5432.

Option A is correct because `kubectl create secret tls my-tls --cert=cert.pem --key=key.pem` is the dedicated command to create a TLS secret, which automatically sets the type to `kubernetes.io/tls` and stores the certificate under the key `tls.crt` and the private key under `tls.key`. This is the standard method for creating secrets intended for use with Ingress resources.

'kubectl port-forward' is used to forward a local port to a pod port. The correct syntax is 'kubectl port-forward pod/debug 4000:80'.

The '--target' flag in kubectl debug specifies the target container for sharing namespaces, including process namespace.

Options A, B, and C are correct: sidecar (adds helper container), adapter (normalizes output), and ambassador (proxies external access). Option D (replicator) is not a standard pattern. Option E (init) is a special container type, not a pattern for multi-container design.

Option A is correct. Headless Services (clusterIP: None) enable DNS to return pod IPs directly, allowing each pod to be reachable via its own DNS name (pod-name.service-name.namespace.svc.cluster.local).

The ResourceQuota in namespace 'dev' has a limit of 8 CPUs for limits.cpu, with 7 already used, leaving only 1 CPU remaining. The pod's container requests a limit of 3 CPUs, which exceeds the available 1 CPU, causing the scheduler to reject the pod and leave it in Pending state. ResourceQuota enforcement occurs at admission time, and the scheduler will not schedule a pod that would cause the namespace to exceed its quota limits.

Init containers run to completion before the main containers start, typically used for setup tasks like waiting for a service or preparing data.

Option A is correct because `kubectl logs -f web-pod` uses the `-f` (follow) flag to stream logs from the pod in real-time, similar to `tail -f` in Linux. This flag keeps the connection open and continuously outputs new log lines as they are written by the container.

A pod with restartPolicy: OnFailure will restart the container if it exits with a non-zero exit code. The pod is Completed, meaning the container exited with 0 eventually, but previous runs exited with non-zero.

A ServiceAccount provides an identity for processes running in a Pod. Option B is partially correct but too narrow; option C is about NetworkPolicy; option D is about RBAC, but ServiceAccount itself is the identity, not the rules.

kubectl top node shows resource usage (CPU and memory) for nodes.

Option A is correct because setting `automountServiceAccountToken: true` in the pod spec overrides the ServiceAccount-level setting of `false`. This allows the pod to mount the service account token automatically, enabling it to authenticate to the Kubernetes API without manual intervention.

Option B is correct because `--from-env-file=app.env` is the dedicated flag for creating a ConfigMap from an environment file, where each line in the file is parsed as a key=value pair. Option C is also correct because `--from-file=app.env` creates a ConfigMap with the file's entire contents stored under the filename as the key, which is a valid method even though it does not parse the file as environment variables.

Option A is correct. kubectl top pod shows resource usage. Option B is for nodes. Option C and D are not valid commands.

helm install with --set and --namespace flags is the correct command.

Option B is correct because `kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` creates a generic secret that stores the contents of an existing Docker config file (typically `~/.docker/config.json`) under the key `.dockerconfigjson`. This is the standard method for importing a pre-existing Docker configuration as a Kubernetes secret, which can then be used for image pull authentication.

Jobs use batch/v1 as of Kubernetes 1.21+.

The HPA will increase the number of replicas to bring average CPU utilization down to the target.

With maxSurge: 1, at most one extra pod can be created above the desired 4. So maximum pods = desired + maxSurge = 5.