Certified Kubernetes Application Developer CKAD (CKAD) — Questions 76–150

The `runAsUser` field in the PodSecurityContext or container SecurityContext sets the user ID (UID) under which the container's main process runs. Setting `runAsUser: 1000` ensures the container runs as a non-root user with UID 1000, meeting the requirement. This field directly controls the effective UID of the process, overriding the default root (UID 0).

Option C is correct because the `kubectl create configmap` command with the `--from-file` flag directly creates a ConfigMap from the contents of a specified file, using the filename as the key and the file content as the value. This is the standard method for creating a ConfigMap from a single file like 'config.properties'.

Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the service account token into the pod. By default, Kubernetes mounts a projected service account token into every pod at `/var/run/secrets/kubernetes.io/serviceaccount`; this field overrides that default behavior at the pod level.

Option B is correct because the `envFrom` field in a Pod spec allows injecting all key-value pairs from a ConfigMap as environment variables into the container. By specifying `configMapRef` with the ConfigMap name, every key in the ConfigMap becomes an environment variable, which matches the requirement to inject all keys without listing them individually.

StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal pod names like `db-0`, `db-1`) and persistent storage per pod (via PersistentVolumeClaims that are retained across rescheduling). This matches the requirement for a stateful database where each pod must maintain its identity and data independently.

With replicas=5 and maxUnavailable=25% (which rounds up to 1), at most 1 pod can be unavailable during the update.

initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, and successThreshold are all valid. The correct three are A, B, C.

The 'OOMKilled' status indicates the pod's container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, a gradual memory leak or increased workload likely caused the usage to spike past the configured limit. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory demand without being killed, resolving the CrashLoopBackOff.

Option C is correct because setting `initialDelaySeconds` in a readiness probe prevents the probe from starting before the container's application has had time to initialize. Without this delay, the probe might fail immediately during startup, causing the container to be prematurely marked as not ready and removed from service, even though the application would have become ready given a few more seconds. This avoids race conditions between container startup and probe evaluation.

Option A is correct because `kubectl create secret tls` is the dedicated subcommand for creating a TLS secret, which automatically encodes the certificate and key files and stores them under the expected keys (`tls.crt` and `tls.key`). This is the only command that produces a secret of type `kubernetes.io/tls`, which is required by Ingress controllers to serve HTTPS traffic.

A is correct because during a RollingUpdate, the new pod must pass its readiness probe before the old pod is terminated. This ensures the new pod is capable of serving traffic, preventing service disruption. The readiness probe is checked by the kubelet, and only when it succeeds does the ReplicaSet controller proceed with the update.

Option B is correct because containers within the same Kubernetes pod share the same network namespace, including the same IP address and port space. This allows them to communicate via localhost and share network resources, which is essential for sidecar patterns like logging agents that need to intercept or monitor the main container's traffic.

Readiness probes determine if a pod is ready to receive traffic. Option A is correct.

Option B is correct because `defaultAddCapabilities` is a valid field in a PodSecurityPolicy (PSP) that specifies a list of Linux capabilities to be added to containers by default, even if not explicitly requested in the container's security context. This field is part of the PSP's capabilities control mechanism, as defined in the Kubernetes PodSecurityPolicy spec.

Use the -c flag to specify the container name when a pod has multiple containers.

An empty ingress rules array in a NetworkPolicy denies all ingress traffic by default. This is a common pattern to isolate pods.

An emptyDir volume is shared between containers in the same Pod and can be used for ephemeral log sharing.

Option A is correct: 'kubectl rollout undo deployment my-deployment'. Option B rolls forward? Option C is not valid. Option D is for history.

A ResourceQuota is a Kubernetes object that enforces aggregate resource consumption limits on a per-namespace basis. It constrains the total CPU, memory, and other resource requests and limits across all pods in that namespace, preventing any single namespace from exhausting cluster resources. Option B correctly identifies this namespace-level resource cap.

maxUnavailable defines the maximum number of pods that can be unavailable during a rolling update. Setting it to 2 ensures at most 2 pods are unavailable at any time.

Option B is correct because it creates a Role in the 'test' namespace with read-only verbs ('get', 'list', 'watch') on pods, and binds that Role to the ServiceAccount 'my-sa' in the same namespace via a RoleBinding. This grants the ServiceAccount scoped, namespace-level read-only access to pods, which matches the requirement precisely.

RoleBindings in Kubernetes are namespace-scoped and can only grant permissions within the namespace where they are created. If the RoleBinding is in a different namespace than the pod, the service account 'my-sa' will not have the get/list pods permissions in the pod's namespace, causing the pod to fail when trying to list pods.

A Deployment is the correct choice for a stateless application that needs identical pods distributed across nodes. It manages a ReplicaSet to ensure the desired number of replicas, supports rolling updates, and provides stable network identities via a headless Service or a regular Service, but the pods themselves do not require stable identities—only the Service provides a stable endpoint. For stateless workloads, Deployments are the standard resource.

kubectl get pod <pod-name> -o yaml outputs the complete YAML. Option A is correct.

Option D (NodePort) is correct because it exposes a service on a static port on each node's IP address, allowing external traffic to reach the 'web-app' deployment on port 8080 without requiring a cloud load balancer. In on-premises clusters, NodePort is the standard service type for external access when no cloud LB is available, as it opens a high-port (30000-32767) on every node that forwards traffic to the ClusterIP service.

The Ingress spec uses the 'host' field under rules to specify host-based routing.

Option B is correct because Pod Security Standards are enforced by applying a label with the key `pod-security.kubernetes.io/enforce` to a namespace. The value `restricted` sets the most restrictive Pod Security Standard, which prevents pods from running with privileged access or insecure capabilities. This label is part of the built-in Pod Security Admission (PSA) controller, which replaced PodSecurityPolicy in Kubernetes v1.23+.

Forbid prevents concurrent runs; the next job is skipped if the previous one is still running.

A ResourceQuota is the correct Kubernetes object to enforce aggregate resource consumption limits at the namespace level. By defining a ResourceQuota with `spec.hard.memory: 10Gi`, you restrict the total memory requested and used by all pods in that namespace to 10 GiB. This directly meets the requirement to limit total memory usage.

The path prefix `/api` matches the start of `/api/v1`, so the request goes to service-a.

schedule, concurrencyPolicy, and successfulJobsHistoryLimit are fields in a CronJob spec. completions is a field in Job spec, not directly in CronJob.

A startupProbe is specifically designed for slow-starting containers. It runs at pod startup and only after it succeeds does the liveness probe begin. This prevents the liveness probe from restarting the container during its 60-second initialization period, as the startupProbe will keep failing until the container is fully ready.

The '--restart=Never' flag sets the restart policy to 'Never', meaning the pod will not be restarted after the container exits.

If no type is specified, the default is ClusterIP.

The correct command is 'kubectl create cronjob' because CronJob is a standard Kubernetes resource. The --schedule flag defines the schedule.

Option A is correct because setting maxSurge=1 allows Kubernetes to spin up one new Pod before terminating any old Pod during a rolling update. This ensures that the total number of available Pods never drops below the desired replica count, maintaining service capacity and achieving zero downtime.

The Recreate strategy first terminates all existing pods, then creates new pods. This ensures that only one version is running at a time, but causes downtime.

The 'kubectl set image' command updates the image of a Deployment's containers. Option A is correct.

ClusterIP is the default Service type, accessible only within the cluster.

Option C is correct because setting `readOnlyRootFilesystem: true` in a container's SecurityContext mounts the container's root filesystem as read-only, preventing any writes to the host filesystem through the container's root. This directly controls access to the host filesystem by blocking modifications. Option D is correct because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent, which restricts the ability to perform privileged operations that could access the host filesystem, such as mounting or modifying host paths.

The .spec.parallelism field sets the maximum number of pods running concurrently, and .spec.completions sets the total number of successful completions required.

Option B is correct because `terminationGracePeriodSeconds` is the Pod spec field that controls the duration Kubernetes waits between sending a SIGTERM signal to the container and forcibly killing it with SIGKILL. Setting this to 30 seconds ensures the application has up to 30 seconds to perform cleanup and shut down gracefully after receiving SIGTERM.

The correct command is 'helm rollback my-app 3'.

A selectorless Service does not automatically create endpoints; the admin must manually create an Endpoints resource to route traffic.

The command 'kubectl create deployment' creates a Deployment with the specified number of replicas.

The default Service type is ClusterIP. Option A is correct. NodePort, LoadBalancer, and ExternalName require explicit specification.

The COPY --from=builder syntax copies files from a previous build stage.

Option D is correct because a startup probe with a low failureThreshold and periodSeconds allows Kubernetes to wait up to 60 seconds (30 failures × 2 seconds) for the application to start, after which the liveness and readiness probes begin. This ensures the liveness probe does not kill the container prematurely during the slow startup, and the readiness probe only directs traffic once the app is fully ready.

maxUnavailable: 2 means at most 2 pods can be unavailable. Option B is correct.

Option C is correct because an init container runs to completion before any main container in the Pod starts, ensuring the database schema script finishes. By mounting the shared volume to both the init container and the main container, the script's output (e.g., schema files) is available to the main application when it launches.

The HPA will increase the number of replicas to bring CPU utilization down towards 80%. The exact new replicas depends on the metric, but generally it scales up.

Option B is correct. With concurrencyPolicy: Forbid, if a previous job is still running, the new job is skipped. The first job is still running after 5 minutes, so the second job is skipped.

Create PVC first, ensure it's bound, then define Pod with volume referencing PVC.

initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, successThreshold are all valid probe parameters.

A Service uses a label selector to dynamically discover Pods and populate its endpoints. When Pod labels are updated, the selector remains unchanged; if the new labels do not match the selector, the Service cannot find any matching Pods, resulting in an empty endpoints list. This is the most direct and common cause of the issue.

Option C is correct because a LimitRange resource in the 'prod' namespace can set a default memory limit and a maximum memory limit per container or pod, enforcing that no pod exceeds 4Gi of memory. This is the appropriate Kubernetes primitive for per-pod resource constraints within a namespace, as it applies to all pods that do not specify their own limits.

A is correct because a Readiness probe determines whether a Pod is ready to serve traffic. If the probe fails, the Pod is removed from the Service's endpoints, preventing traffic from being routed to an unready container. This is essential for rolling updates and graceful shutdowns.

Option A is correct because `ephemeral-storage` is a valid resource type in Kubernetes that can be specified under `resources.limits` to control the maximum temporary storage a container can use, preventing pods from exhausting node storage. This is defined in the Kubernetes resource model and is commonly used for scratch space or logs.

Option B is correct because a ResourceQuota can enforce that every Pod in the namespace has resource limits set by specifying the `limits.cpu` and `limits.memory` fields in the quota's `hard` spec. If a Pod is created without those limits, the API server will reject it, ensuring no Pod runs unbounded. This is distinct from setting default values, which is done by a LimitRange, not a ResourceQuota.

Option B is correct because a sidecar container can share the application's log file via an emptyDir volume, read the raw logs, apply redaction logic (e.g., regex replacement of password patterns), and then output the sanitized logs to its own stdout. This approach satisfies the security requirement without modifying the application code or losing log verbosity, and it keeps the redaction logic decoupled from the main container.

Option B is correct because readiness probes are designed to run continuously throughout the lifecycle of a container, not just during startup. They are periodically executed by the kubelet to determine whether the container is ready to accept traffic, and their success or failure directly controls the pod's inclusion in Service endpoints.