Certified Kubernetes Application Developer CKAD (CKAD) — Questions 226–300

For a headless Service to publish A records, its selector must match the pod labels of the StatefulSet's Pods; the DNS entries are generated from the Service's endpoints. If the selector matches no Pods, the endpoints list is empty and the cluster's DNS resolver returns NXDOMAIN (or no A record) for the fully-qualified domain name. So even with clusterIP set to None, you get no DNS results, which is exactly why this is the correct answer.

Valid type.

terminationGracePeriodSeconds is the correct Pod-level setting that determines how long Kubernetes waits between sending SIGTERM and the forced SIGKILL when a Pod is being terminated. This gives the main container process time to flush state, close connections, and complete cleanup. It is configurable per Pod in the Pod spec and defaults to 30 seconds; setting it appropriately is essential for graceful shutdown.

A RoleBinding is the mandatory link that assigns the Role's permissions to a subject, such as a User, Group, or ServiceAccount, within a namespace. Without it, the Role exists in isolation and grants nothing. It also allows binding a ClusterRole, but here it binds the Role you created, completing the RBAC grant.

When you run kubectl scale deployment demo --replicas=5, the Deployment's scale subresource is updated, and the Deployment controller reconciles by adjusting the desired replicas on the currently active ReplicaSet. Because the pod template is unchanged, no new ReplicaSet is created or replaced; the existing ReplicaSet's spec.replicas is set to 5, and its controller creates exactly two new pods to go from 3 to 5 running instances.

concurrencyPolicy is a legitimate CronJob.spec field that controls how the controller handles Jobs that should be created while another Job from the same CronJob is still active. It accepts Allow, Forbid, or Replace; Allow starts a new Job immediately, Forbid skips the new run until the next schedule, and Replace cancels the active Job before starting a new one. This is a top-level scheduling-policy field, not something inherited from the Pod or Job template.

LoadBalancer is correct because it instructs the cloud provider (e.g., AWS, GCP, Azure) to provision an external load balancer and assign a stable, publicly reachable IP address or DNS name. This traffic is automatically forwarded to the Service's backend pods, abstracting away node IPs and providing health checks and auto-scaling of the underlying infrastructure. It is the standard way to expose a Service to internet-facing external clients.

Setting clusterIP: None creates a headless Service, which publishes the individual pod IPs and DNS names for a StatefulSet. When the selector matches the pods, Kubernetes creates A records like mysql-0.mysql.namespace.svc.cluster.local for each replica, enabling clients to address a specific pod. This is the correct way to provide stable network identities for stateful applications, which is exactly what a StatefulSet requires.

In a headless Service (`clusterIP: None`), DNS records are generated per ready Pod rather than for a single virtual IP. By default, Kubernetes excludes Pods whose readiness condition is false from DNS A/AAAA record lists, which means a not-ready backend Pod will not appear as a DNS entry and the frontend cannot reach it by name. Adding `publishNotReadyAddresses: true` to the Service spec instructs the cluster DNS to publish the addresses of all backing Pods regardless of readiness, enabling the frontend to discover even not-ready backends. This is the only correct option because it identifies the missing configuration attribute that directly affects DNS population.

This is the correct Helm conditional: `{{- if` trims all whitespace before it so the ConfigMap YAML sits directly at the intended indentation level, and `{{- end }}` trims the trailing whitespace after the block. Helm checks whether `.Values.config.enabled` evaluates to a truthy value (true for booleans, non-empty for strings/lists/maps) and renders the enclosed YAML only in that case. The dash (`-`) is critical for producing clean YAML without stray blank lines that can break resource parsing.

Kubernetes projects the service account token into every pod at a fixed projected volume path. Reading /var/run/secrets/kubernetes.io/serviceaccount/token supplies the bearer token the pod presents to the API server, resolving the 403 caused by missing authentication.

When runAsUser overrides the image's declared USER to 2000 while the application's files and configuration expect uid 1000, the process can't read or write its own runtime files, often encountering 'permission denied' at startup. This manifests as the container exiting immediately with a non-zero code, which Kubernetes reports as CrashLoopBackOff. The fix is to set runAsUser to 1000 or adjust file ownership to match 2000.

NodePort is a valid Kubernetes Service type that builds on ClusterIP by additionally opening a static port (30000–32767 by default) on every node. Traffic sent to that nodePort is forwarded to the ClusterIP, then to backend Pods via the Service's selector. It is used when external clients need to reach a Service without a cloud load balancer, though it exposes the Service on each node's IP address and thus requires knowing node addresses and handling potential port collisions.

A Service of type LoadBalancer instructs the cloud provider's controller to provision an external load balancer and route traffic to the backing pods. This satisfies the requirement for external accessibility through the provider's load balancer, unlike ClusterIP or NodePort.

kubectl top pod is the correct command because it queries the metrics API (typically backed by metrics-server) to retrieve and display live CPU and memory usage for each pod. It shows current resource consumption at the container and pod level, and optionally displays per-container details with the --containers flag. This makes it the standard command for quick, immediate resource observation.

runAsUser is a valid field in PodSecurityContext, specifying the numeric UID that all containers in the pod must run with. It overrides any user defined in the container image, enforcing a non-root user consistently across the pod. This field is also available at the container level, but when set at the pod level it applies to every container unless an individual container overrides it.

This command directly queries the Endpoints API object that shares the Service's name, displaying the backend pod IPs and ports that the ClusterIP Service routes to. When the selector no longer matches any pods, the output shows `<none>` for the endpoints list, confirming there is no backing set of pods. It is the canonical way to verify the existence (or absence) of endpoints for a Service.

runAsNonRoot: true is a securityContext validation that ensures the container will not start if it is configured to run as root. Kubernetes checks the user defined in the image metadata (or the runtime user) and refuses to launch the pod if the UID is 0 or unspecified. This directly enforces the non-root requirement, providing a hard guarantee that the container runs with an unprivileged user ID. It is the only option that actively prevents root execution, making it the correct choice for this question.

In Kubernetes Jobs, the 'parallelism' field specifies the maximum number of Pods that may run concurrently. Here it is explicitly set to 3, so at most three Pods will be active at any given time, regardless of how many have completed. Completions only sets the total number of successful Pods required (6), not the concurrency limit.

Editing the Deployment's pod template and applying the manifest updates the desired state, which makes the Deployment controller create a new ReplicaSet while scaling down the old one according to the configured strategy (default RollingUpdate). New pods are launched with the increased memory limit, and old pods are terminated only once the new ones are Healthy, keeping the service available throughout. Because the Pod spec is immutable, the template change is the declarative, supported path to alter resources without manual pod handling.

This is the correct syntax for referencing a single key from a ConfigMap. The valueFrom.configMapKeyRef field tells Kubernetes to look up the ConfigMap named db-config, read the value stored under the key url, and assign it to the environment variable DB_URL. This enables precise, selective injection of configuration data without importing the entire ConfigMap.

Restricted is a valid Pod Security Admission standard, representing the most stringent level. It enforces namespaces and pods to follow best practices such as disallowing privileged containers, dropping all capabilities, and setting a non-root user. This standard is often chosen for sensitive production workloads to minimize container escape risks.

Kustomize's overlay mechanism layers environment-specific patches on top of a base kustomization, allowing you to modify replicas, images, or namespaces per environment. The base directory holds common resources, and overlays reference it via a `kustomization.yaml` with fields like `resources` and `patchesStrategicMerge`. This avoids duplicating manifests and keeps a single source of truth across dev, staging, and production.

`kubectl rollout status deployment web-app` is the correct command to monitor a Deployment's rollout progress. It blocks and repeatedly polls the Deployment's status, providing real-time updates until the rollout completes successfully, or it exits with an error if the rollout gets stuck. This command is specifically designed to report the rollout state, waiting for the new ReplicaSet to become fully available.

kubectl apply computes a patch between the desired configuration in your file and the current live object, then merges changes into the existing resource, thus it can update resources. In contrast, kubectl create sends a POST request to the API server and expects to create a brand-new object; if the resource already exists, the API server returns a 409 Conflict error. This fundamental difference makes apply the preferred tool for declarative updates.

This command is correct because `--from-file=config.properties` instructs kubectl to create a ConfigMap whose data contains a single key `config.properties` (the file basename) with the file's full contents as its value. This is the standard, documented way to import a file verbatim into a ConfigMap, and it does not require any extra flags or formatting assumptions about the file's internal structure.

Setting `runAsUser: 999` explicitly instructs the kubelet to start the container process with UID 999, which is non-zero. This satisfies the `runAsNonRoot: true` validation because the runtime verifies that the effective UID is not 0. Since the Postgres image commonly defines a `postgres` user with UID 999, this aligns with the image's intended user and avoids running as root. This is the standard, least-privilege fix for a `runAsNonRoot` enforcement failure.

Using `kubectl create configmap app-config --from-literal key1=value1 --from-literal key2=value2` is correct because the `--from-literal` flag is designed to accept exactly one `key=value` pair, and repeating the flag accumulates each pair into the ConfigMap's `data` field. This is the canonical CLI syntax for defining inline literals directly from the command line, with no dependency on files or external input.

The `kubectl scale` command is the canonical Kubernetes imperative operation for altering the desired replica count of a resource. Using `deployment api --replicas=5` explicitly identifies the resource type and name while supplying the target count through the mandatory `--replicas` flag. This triggers the scale subresource of the Deployment, updating its `spec.replicas`, and the corresponding ReplicaSet controller then adjusts pods to match. This syntax is correct because every required argument is provided and no invalid flags are used.

In a headless service, no cluster IP is allocated, so the DNS name for the service resolves directly to the set of pod IPs that match its selector. Kubernetes DNS, typically CoreDNS, returns a separate A record for each matching pod IP, allowing clients to discover and connect to each pod independently. This behavior is essential for peer discovery in StatefulSet-based distributed systems, where each replica must be addressed individually.

This correctly sets `maxSurge: 50%` and `maxUnavailable: 25%`, which are the exact fields and values requested for managing the rolling update. With four replicas, 50% surge translates to two extra pods (rounded up), allowing up to six pods, while 25% unavailable translates to one pod down (rounded down), guaranteeing at least three pods remain available during the update. This is the valid YAML representation of a rolling update with a 50% surge and 25% maximum unavailability.

A RoleBinding always grants permissions only in the namespace where the binding itself is defined, regardless of whether it references a Role or a ClusterRole. Here, the ClusterRole supplies the pod read rules (get, list, watch), but the RoleBinding limits those rules to the 'default' namespace. As a result, Jane can read pods only in that namespace, not in any other.

This is the correct command because it directly queries the metrics API for pod-level CPU and memory usage from the Metrics Server. The `-n` flag scopes the output to a specific namespace, and when combined with a pod name or label selector it shows live resource consumption for those pods. Without `-n`, it defaults to the current namespace, but specifying it explicitly ensures you are viewing the intended namespace.

This is the correct explanation. The Ingress resource specifies 'ingressClassName: nginx', but if no IngressClass named 'nginx' exists, or the NGINX Ingress controller is not installed and configured to watch that class, the Ingress will have no active controller to reconcile it. As a result, no forwarding rules are programmed into any reverse proxy, and requests to '/api' produce a 404. Without a matching IngressClass and running controller, the Ingress is effectively inert.

The --previous flag specifically tells kubectl to display logs from the prior container instance that ran in the pod, typically one that has terminated due to a crash or a restart. The kubelet retains the terminated container's logs in a separate file, and this flag directs kubectl to that historical log while ignoring the current container's output. This is exactly what you need to diagnose why a container previously crashed, as it shows the last output before the failure.

Updating the Service's label selector to match the green Deployment's pod labels is the correct control point for traffic shifting. When the selector changes, the EndpointSlice controller re-evaluates matching Pods and replaces blue pod IPs with green pod IPs, atomically switching the backend. This approach preserves the ability to instantly roll back by reverting the selector to blue labels, provided the blue Deployment remains available.

This command queries the Metrics Server through the metrics.k8s.io API and prints per-container CPU and memory usage for the named pod. The --containers flag is required to break the output down by container when a pod has more than one, and it works fine for single-container pods too, giving exactly the usage figures needed to spot throttling.

The readiness probe is the correct mechanism because it directly controls whether a pod is added to or removed from the endpoints of a Service. When the probe fails, the kubelet marks the pod as NotReady, and the endpoints controller immediately removes its IP from all backing Services, stopping new traffic. This is essential for deployments where the application needs time to warm up or load data before accepting requests, and it also enables zero-downtime rolling updates by holding back new pods until they are fully operational.

This is the correct specification because completions 10 and parallelism 10 work together to meet the requirement: the Job controller launches up to 10 Pods concurrently (parallelism), and the Job is considered successful only after 10 distinct Pods complete successfully (completions). Each Pod can handle one of the 10 items, all run in parallel, and the Job waits until every one has finished. The combination precisely matches the stated batch workload.

With maxSurge=0, the desired replica count cannot be exceeded, and with maxUnavailable=1, at most one pod may be down during the update. This configuration forces a strictly sequential pattern: the controller first terminates an old pod, which counts as one unavailable pod, then creates a new pod to restore the replica count to the desired number. It then repeats this cycle for each remaining old replica, so one old pod is terminated, a new pod is created, and this continues until all pods are rolled over. This approach maintains availability without any temporary scaling up.

Setting spec.parallelism: 3 tells the Job controller to run up to three Pods concurrently, meaning the Job will schedule three Pods at the same time rather than a single Pod. This field directly controls the degree of parallelism; for a fixed-completion Job, the controller keeps parallelism Pods active until the desired completions count is reached. To achieve exactly three Pods running in parallel, parallelism is the correct knob to use.

LimitRange's spec.default section defines default resource requests and limits for containers that do not explicitly declare them. When a pod is created in a namespace with a LimitRange, any container lacking a request or limit for a resource specified in default is automatically assigned that value. This defaulting mechanism applies at admission time, so it does not retroactively modify existing pods, and it works alongside the min/max constraints to keep pods within acceptable boundaries.

Probe failures are surfaced as events on the pod, and the message includes the probe type, the failure detail, and the endpoint being tested. That directly shows whether the kubelet is dialing the wrong port or path, or whether the application is returning a failing status, which is exactly the distinction the engineer needs before changing anything.

This is the correct NetworkPolicy because `spec.podSelector` matches only the protected pods labeled `app=myapp`, and the single `ingress` rule uses a `from` clause with a `podSelector` that matches source pods labeled `role=frontend`. By defining only this rule and no default `ingress` rules, the policy defaults to denying all other incoming traffic to those pods while explicitly permitting traffic from the intended frontend pods. The use of `podSelector` for both the target and the source ensures precise, pod-level control over allowed ingress.

spec.backoffLimit: 3 is the correct field because it directly defines how many times the Job controller will re-create a pod after it fails. The initial pod run counts as the first attempt, and each subsequent re-creation is a retry, so with backoffLimit set to 3, there are exactly 3 retries and a total of 4 attempts. This precisely matches the requirement and is the standard approach for controlling retry attempts in a Kubernetes Job.

Configuring ingress controllers with specific settings like rewrite rules is a valid use of annotations because ingress controllers (e.g., NGINX, Traefik) are designed to read controller-specific annotations attached to the Ingress resource to customize routing behavior. For example, `nginx.ingress.kubernetes.io/rewrite-target` instructs the NGINX controller to rewrite request paths before proxying them to backend services. These annotations act as declarative configuration that the controller consumes, while the core Ingress spec remains portable across different controllers.

In a Kubernetes Job, backoffLimit defines the number of retries before the Job is considered failed. The backoffLimit field is set to 4, meaning the controller can retry the Pod up to 4 times after a failure. After those 4 retries are exhausted, the Job transitions to the Failed condition. Thus, the correct number of retries is exactly 4.

kubectl exec pod-name -- env executes the env binary as a separate process inside the container's namespaces, printing all environment variables visible to that process. The -- delimiter tells kubectl that everything after it is a command to run inside the container, not a flag for kubectl itself. This non-interactive, single-command invocation is exactly suited for checking environment variables.

This is correct because the egress rule uses the 'to' field, which is the required selector for defining destination traffic, and the podSelector with matchLabels 'db: mysql' limits allowed destinations only to pods carrying that label. The spec is otherwise valid because it requires no namespaceSelector, meaning it selects pods in the same namespace as the NetworkPolicy, which is the expected scope for this scenario. The policy permits egress only to those labeled pods while implicitly denying all other destinations.

kubectl create deployment webapp --image=nginx:1.25 --replicas=3 is the canonical imperative command that generates a Deployment named 'webapp' with the specified container image and desired replica count. The --replicas flag is explicitly supported by kubectl create deployment, and the resulting Deployment object will manage three Pod replicas using the nginx:1.25 image. This fully satisfies the requirement to create a Deployment with those parameters.

This is exactly what concurrencyPolicy: Replace does. When the CronJob controller fires a new schedule, it checks whether the Job from the previous invocation is still active; if so, it deletes that existing Job (terminating its Pods) and creates a fresh Job for the current run. This ensures the schedule is always honored and only one Job's worth of work executes at a time.

helm list is the correct command because it queries the Helm storage backend in the current Kubernetes namespace and returns all installed releases with their name, status, revision, update time, and chart version. You can filter with flags like --namespace and --all-namespaces, and by default it excludes uninstalled releases.

A `maxSurge` value of 1 correctly indicates that exactly one pod may be created above the desired replica count during a rolling update. This allows the Deployment controller to bring up a new pod before terminating an old one, reducing downtime while keeping the surge limited to a single extra pod. Kubernetes interprets this as an absolute number, so the controller ensures the total pod count never exceeds `replicas + 1` during the update.

This field is the authoritative control for how long the kubelet will wait between sending SIGTERM and SIGKILL to a container during pod termination. Setting it to 60 explicitly grants the main process a 60-second window to handle the signal and shut down gracefully, whereas without it the default is only 30 seconds. This is the only direct mechanism for ensuring the pod receives SIGTERM and has time to react.

A LimitRange is a namespaced Kubernetes object that sets minimum, maximum, and default values for CPU and memory requests and limits for individual containers or pods. When a container is created without explicit resources, the LimitRange admission plugin automatically injects defaults, and if the container's declared limits fall outside the configured range, the pod is rejected. This gives operators precise, per-pod control over how many resources each workload can consume.

Init containers are special containers that run to completion sequentially before any regular containers in the pod start. Each init container must finish successfully before the next one begins, and the main container is only started after all init containers have succeeded. This makes them the correct choice for initialization tasks such as setting up volumes, waiting for dependencies, or performing migrations. If an init container fails, it is retried according to the pod's restartPolicy, ensuring the main container never starts prematurely.

The `secretKeyRef` field is the correct and standard mechanism for referencing a key from a Kubernetes Secret object and injecting its value as an environment variable. It requires the Secret to exist in the same namespace and the referenced key to be present; otherwise, the container creation fails. This approach keeps sensitive data out of the Pod manifest and centralizes it in the Secret API, which is the intended and secure pattern.

UnlessStopped is not a recognized value for the restartPolicy field in Kubernetes; the only valid values are Always, OnFailure, and Never. It might sound familiar from Docker's own restart policies, but Kubernetes deliberately does not implement it. Attempting to use UnlessStopped in a Pod manifest will cause the API server to reject the definition with an invalid value error.

This is the precise imperative command to add an annotation to a Pod object in the cluster. `kubectl annotate pod my-pod key=value` directly updates the `metadata.annotations` map of the specified Pod, and the change is immediately visible to the API server. This approach works for any Pod, but it is especially appropriate when the Pod is statically created or when you intentionally want to modify only the live object. For controller-managed Pods, remember that this change is ephemeral — if the Pod is recreated by its Deployment or ReplicaSet, the annotation will be lost unless the Pod template is also updated.

Relying solely on CPU utilization can miss memory-bound workloads, where pods degrade due to memory pressure long before CPU approaches its target. Adding a memory metric to the HPA—using targetAverageValue or targetAverageUtilization—makes the autoscaler react to actual resource exhaustion. Since memory is a non-compressible resource, Kubernetes cannot throttle it as it does with CPU, so the only effective mitigation is to add replicas when average memory consumption exceeds the configured threshold.

This command creates a temporary pod named 'tmp' using the busybox image, sets restart policy to Never, attaches interactively, and removes the pod after exit. The '--' separates the kubectl arguments from the command to run in the container, which is 'wget -qO- http://web-svc'. This is the correct way to launch an interactive pod and execute a command.

fsGroup is a pod-level securityContext field that specifies the group ID for volume ownership. When set, Kubernetes changes the group ownership of volumes mounted into the pod (except Secrets and ConfigMaps) to that GID, and files created in those volumes will also inherit this group. This ensures containers have consistent group-based access to shared volumes, even when runAsGroup differs, because fsGroup applies at the mount layer.

Setting `runAsNonRoot: true` forces the kubelet to refuse container startup if the image resolves to UID 0, satisfying the restricted profile's mandate that containers never run as root. This directly enforces the non-root user constraint, one of the three baseline hardening controls the restricted profile requires.

helm history frontend --namespace web is the correct command to display the full revision history for the release named 'frontend' in the 'web' namespace. It outputs a table with each revision number, the chart and app version used, the status (e.g., superseded, failed, deployed), a description of the action (install, upgrade, rollback, or test), and the timestamp of the operation. This provides an audit trail that lets you verify when changes occurred, investigate unexpected behavior, and choose a revision for potential rollback, making it the appropriate command for the question.

Setting automountServiceAccountToken: false only disables the automatic mounting of the service account token; it does not prevent you from mounting it explicitly. You can add a projected volume in the Pod spec with the serviceAccountToken source, specifying the service account name, path, audience, and expiration seconds. Then add a volumeMount at an application-accessible path (e.g., /var/run/secrets/token) so the container reads the token from that file. This is the correct way to restore API access while keeping the automatic mount disabled.

When a pod's CPU request exceeds the total allocatable CPU capacity on every node in the cluster, the kube-scheduler cannot find a feasible node and leaves the pod in Pending state. The scheduler compares each node's allocatable CPU against the sum of requests for all pods, and a `FailedScheduling` event with `Insufficient cpu` is recorded. This is a scheduling failure, not a runtime failure, so the pod remains Pending until a node with enough free CPU becomes available.

The --previous flag explicitly instructs kubectl to retrieve the logs written by the most recent terminated container instance of the pod. When a container has crashed or restarted, this shows the complete stdout/stderr from the old instance, which is often the only source of diagnostic information about the failure. It is the straightforward, unambiguous long-form command for viewing previous container logs.

In a headless service, the DNS A record query resolves directly to the IP addresses of all pods backing the service, rather than to a single ClusterIP virtual IP. Because clusterIP is set to None, no load-balanced IP exists, and the DNS server returns a set of A records, each corresponding to an individual pod endpoint, allowing clients to contact those pods directly.

This is the textbook blue-green cutover. By changing the Service's selector to 'app: myapp, version: green', the Service will match only the pods belonging to the green Deployment, since those pods carry both labels. The blue pods remain running but are no longer selected, so all incoming traffic is instantly redirected to the green version. This is a declarative, reversible change that requires no pod restarts, making it the simplest and standard approach.

This rule correctly combines a namespaceSelector and a podSelector within the same ingress peer, and in NetworkPolicy semantics, these two selectors are ANDed when they appear together in a single peer. Thus, only pods that simultaneously satisfy both labels—role=proxy on the pod itself, and the pod's namespace having name=frontend—are allowed as sources. This exactly matches the stated requirement, ensuring no other pods from the frontend namespace, and no proxies from other namespaces, can connect.

This is the exact definition. During a rolling update, the Deployment controller ensures that at most maxUnavailable pods (default 25% of desired replicas, rounded to an integer) are out of service at any moment. It gives you control over the trade-off between update speed and service availability, allowing you to keep most of your workload serving traffic while the rest are replaced. This setting is evaluated continuously, so even if one pod fails to become ready, the controller pauses further changes to maintain the unavailability limit.

kubectl debug with an explicit image creates an ephemeral container that is injected directly into the existing Pod, even when its primary container is not running. This ephemeral container shares the Pod’s network, storage, and optionally its process namespace, letting you inspect crashed processes or mounted volumes from inside the Pod context. The interactive -it session gives you a shell without ever needing the original container to be alive, which is precisely why it succeeds where exec, attach, or a separate run would fail.

FROM declares the base image that subsequent build stages start from, pulling it from a registry or referencing a prior build stage. It must be the first instruction in a stage, establishing the filesystem and environment on which RUN, COPY, and other instructions operate.

kubectl describe pod outputs a detailed, human-readable summary of a pod's current state, including its metadata, spec, status, conditions, container states, restart counts, and, notably, a tail of recent events from the Kubernetes event stream. This event history is essential for debugging because it reveals scheduler decisions, image pull outcomes, and liveness/readiness probe failures that are not visible in the pod's YAML or its logs.