Certified Kubernetes Application Developer CKAD (CKAD) — Questions 601–675

To prevent scaling down, you can set a stabilization window on the scaleDown policy. Option B correctly sets a stabilizationWindowSeconds in the scaleDown behavior.

Option C (NET_ADMIN) is correct because it is a Linux capability that can be added to a container's securityContext under the `capabilities.add` field. This capability allows the container to perform network administration tasks such as interface configuration, firewall management, and routing table manipulation, which are common in network-focused pods.

Option A is correct because it defines a Role in the 'app' namespace with rules allowing 'get' and 'list' verbs on 'pods', and binds that Role to the 'monitor' ServiceAccount using a RoleBinding in the same namespace. This grants the ServiceAccount the exact permissions needed to list pods within the namespace, following the principle of least privilege.

Option A is correct. A default-deny ingress policy has an empty podSelector (meaning all pods) and no ingress rules, blocking all incoming traffic.

The 'maxUnavailable' field in a Deployment's rolling update configuration specifies the maximum number of Pods that can be unavailable during the update process, relative to the desired replica count. This ensures that a controlled number of Pods are taken down at a time, maintaining application availability while the update progresses. It is defined as either an absolute number or a percentage of the desired replicas, and it works in conjunction with 'maxSurge' to control the update pace.

The `seccompProfile` field in a Pod's SecurityContext allows you to specify a seccomp profile to restrict system calls. Setting it to `RuntimeDefault` applies the container runtime's default seccomp profile, which blocks a set of dangerous syscalls while allowing normal operation. This is the correct field to enforce a seccomp profile of 'RuntimeDefault'.

Option D is correct because the `--previous` flag in `kubectl logs` retrieves logs from the previous instantiation of a container in a pod that has crashed or restarted. This allows you to inspect the logs from the terminated container before the current running instance, which is essential for debugging why the pod is not responding as expected after a crash.

Option B is correct because it uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Secret named 'mysecret' and inject its value into the environment variable `SECRET_DATA`. This is the standard Kubernetes syntax for exposing a Secret's key-value pair as an environment variable.

Option A is correct because `kubernetes.io/tls` is a built-in Secret type used to store TLS certificates and private keys, typically for ingress TLS termination. This type expects the data keys `tls.crt` and `tls.key` and is automatically validated by Kubernetes to ensure the certificate and key are properly paired.

kubectl scale is the correct command to change the replica count of a deployment.

Option B is correct because the Service's `targetPort` must match the `containerPort` defined in the pod's container spec. If they differ, the Service will not route traffic to the pod, and the pod will not appear in the Endpoints object, even if the label selector matches. Kubernetes validates the endpoint population by checking that the pod's readiness probe passes and that the target port is reachable on the pod's IP.

Setting `securityContext.readOnlyRootFilesystem: true` makes the container's root filesystem read-only, preventing an attacker who gains access from modifying system binaries, libraries, or configuration files. This is a key defense-in-depth measure that limits the impact of a compromise by restricting write access to only explicitly mounted volumes.

Option D is correct because `journalctl -u kubelet` directly queries the systemd journal for logs from the kubelet service on the node. Since the kubelet is not responding, you cannot use `kubectl` to access its logs remotely; you must SSH into the node and use `journalctl` (or `systemctl status kubelet`) to read the kubelet's logs locally.

When a Pod has `runAsNonRoot: true` in its security context and the container image runs as root (UID 0), the Pod will not be created. Kubernetes validates this at admission time (via the PodSecurity admission controller or a validating webhook) and rejects the Pod with an error indicating a security context violation. This is because `runAsNonRoot: true` enforces that the container must not run as UID 0, and the image's default user is root, so the Pod fails creation immediately.

Option D is correct because `kubectl describe pod <pod>` provides detailed event logs and status conditions for the pod, including specific error messages like 'failed to provision volume with StorageClass' or 'storageclass.storage.k8s.io "<name>" not found'. This directly confirms whether a missing storage class is the root cause of the 'ContainerCreating' state, as the pod's events will surface the exact provisioning failure.

Options A, C, and E are correct. 'kubectl rollout undo' can rollback to a previous revision (A), can specify a revision (C), and is available for DaemonSets (E). Option B is false because it doesn't delete the Deployment. Option D is false because 'undo' is used for rollback, not pause.

parallelism defines the maximum number of pods running concurrently.

If you create a Service without specifying type, it defaults to ClusterIP, which makes the service accessible only within the cluster.

Option A is correct because Pod Security Admission (PSA) supports three modes: enforce (blocks violations), audit (logs violations in audit logs), and warn (returns a warning to the user). This allows administrators to test or monitor PSA policies without immediately blocking pod creation, which is critical for gradual adoption.

The VOLUME instruction creates a mount point for externally mounted volumes or other containers.

The kubectl top pod command shows resource usage for pods.

kubectl scale can change the replica count of a Deployment.

This policy selects all pods and has empty ingress and egress rules, which default to denying all traffic. Egress to DNS is blocked.

A, B, D are correct. Ingress resource defines rules, Ingress controller implements them, and Service routes to pods. C is not required; E is optional but not typically involved.

Option D is correct because container logs provide the application's perspective on why the HTTP endpoint is failing intermittently. The liveness probe failure is a symptom; the root cause (e.g., a transient error, resource exhaustion, or a bug) is most directly visible in the application's own log output around the failure timestamps. This aligns with the CKAD domain of Application Observability and Maintenance, where logs are the primary diagnostic tool for application-level issues.

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

Option A is correct because `kubectl create secret generic` with `--from-literal` is the standard way to create a generic (Opaque) Secret from key-value pairs directly in the command line. Each `--from-literal` flag specifies a key=value pair, and the command creates a Secret named 'db-creds' with keys 'username' and 'password'.

If the Ingress controller returns 404, often the backend Service or its endpoints are not correctly configured or the Service does not have matching selectors.

kubectl scale deployment frontend --replicas=10 is the correct command.

The Recreate strategy terminates all existing pods before creating new ones. All 3 pods will be terminated simultaneously, then new pods are created.

In the Ingress spec, under tls, the secretName field specifies the Secret containing the TLS certificate and key.

Option B is correct because Pod Security Admission (PSA) is a built-in admission controller that requires the PodSecurity feature gate to be enabled on the API server (and, for enforcement, the kubelet must also support it) to activate the admission webhook. Without this feature gate, the PSA labels on namespaces are ignored, and the restricted policy cannot be enforced.

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

To route based on host, you use the 'host' field under rules. For default backend (no host match), you specify a default backend at the spec level. The correct YAML has two rules: one with host and one without (or a default backend).

The default restart policy is Always for pods created by kubectl run without --restart flag.

The form is <service>.<namespace>.svc.cluster.local.

The DNS server IP 10.96.0.10 is the default ClusterIP of the kube-dns Service. If the pod can't resolve a Service in the same namespace, it's likely that the DNS service is not running or the pod's DNS policy is incorrect. However, the most common issue is that the kube-dns Service is not reachable due to network policy or the kube-dns pods are not running.

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

A timeoutSeconds value lower than the application's response time can cause the probe to fail even if the app is healthy. Option C is correct.

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

StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal hostnames) and ordered, graceful deployment and scaling (pod creation/deletion in sequence). This matches the requirements for a stateful database cluster where each pod requires its own PersistentVolumeClaim (PVC) and stable identity for clustering.

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

NodePort exposes the Service on a static port on each node's IP address.

NodePort exposes a service on a static port on each node's IP, allowing external access via NodeIP:NodePort. Port 30080 is a valid NodePort range (30000-32767).

Kustomize expects a kustomization.yaml file in each layer. The base has its own kustomization.yaml that includes resources, and the overlay has a kustomization.yaml with a bases field pointing to the base path.

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

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

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

A is correct because `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent, such as via setuid binaries or file capabilities. Setting it to `false` prevents privilege escalation, which is a core security requirement for restricting container breakout.

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

Option B is correct. For a Job that runs many parallel tasks, you use a work queue pattern with a fixed completion count. spec.parallelism sets the number of pods to run in parallel, spec.completions sets the total number of successful completions required, and spec.backoffLimit sets the number of retries before considering the Job as failed. The spec.backoffLimit field is the correct way to limit retries; spec.activeDeadlineSeconds is a time limit, not a retry limit.

IngressClass allows selecting a specific Ingress controller implementation to handle the Ingress resource.

Headless services are used for StatefulSets to allow pod-to-pod DNS resolution. They also enable custom load balancing or when you don't need a single IP.

The kubectl rollout status command tracks the progress of a deployment rollout.

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

With 'Forbid', if a job is still running, the new scheduled job is skipped (does not run).

Helm releases are tracked in the cluster, and each install creates a new release.

NodePort exposes the service on each node's IP at a static port (30000-32767).

kubectl set image and kubectl edit are valid ways to update a Deployment's image. Option A and D are correct.

First, resume the rollout with 'kubectl rollout resume deployment/<name>', then check status with 'kubectl rollout status deployment/<name>'. Option B is correct.

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

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