Certified Kubernetes Application Developer CKAD (CKAD) — Questions 451–525

Liveness probes are the kubelet's health check for container liveness; if a liveness probe fails, the kubelet kills the container and restarts it according to the pod's restartPolicy (default is Always). This is the standard self-healing mechanism designed to recover from deadlocks, unbounded memory leaks, or hung processes. When a developer sees a pod restart, the most common cause is an unhealthy container being restarted by a failed liveness probe. The event for this would be 'Liveness probe failed' with a subsequent container recreate.

maxSurge is a valid field within the `rollingUpdate` configuration. It specifies the maximum number of pods (or a percentage of desired pods) that can be created above the desired replica count during an update. This controls how quickly the Deployment can add new pods while maintaining available capacity, and it works together with maxUnavailable to define the update's pace.

values.yaml is the default source of user-supplied configuration for a Helm chart. During chart rendering, the template engine merges values.yaml with any --set or -f overrides, and the resulting object is exposed as .Values in Go templates.

The `kubectl describe` output would show an event indicating that each node has a taint such as `node.kubernetes.io/disk-pressure`. Because the pod defines no tolerations for that taint, the scheduler filters out those nodes, leaving the pod Pending. Disk pressure is a node condition that the kubelet automatically encodes as a taint, and pods must explicitly tolerate it to be scheduled. This matches the event description exactly, unlike resource-based failures.

The correct configuration under a container's securityContext is seccompProfile, and setting its type to RuntimeDefault tells the container runtime to apply its built-in default seccomp profile. This profile restrictively filters syscalls, blocking dangerous ones while allowing normal operation, without requiring you to ship a custom profile. It is the preferred way to enable seccomp in modern Kubernetes because it delegates the policy to the runtime, which is already tuned for safe defaults.

kubectl apply performs a merge-patch on an existing object's desired state, so it can seamlessly update a resource that already exists in the cluster, whereas kubectl create sends POST requests to the API server and receives an AlreadyExists error if the resource is present. This distinction is fundamental: create is for initial provisioning only, while apply is idempotent and safe to run multiple times, making it ideal for declarative configuration management in CI/CD pipelines.

Readiness probes determine pod readiness; failing pods are removed from Service endpoint slices, so kube-proxy stops forwarding traffic to them. This directly satisfies the stem's requirement to control whether the pod receives traffic from Services, unlike liveness probes which restart containers.

This is the dedicated command for viewing rollout history. It lists revisions (e.g., 'REVISION CHANGE-CAUSE'), showing each revision number and the change cause (if annotations are set). It reads the revision history stored in the Deployment's ReplicaSets. This command is specifically designed for that purpose.

This is the correct command to create a TLS secret: it generates a Secret with the type `kubernetes.io/tls` and stores the contents of `cert.pem` under the `tls.crt` data key and `key.pem` under the `tls.key` data key. The `--cert` and `--key` flags are required and must point to PEM-encoded files. After creation, the secret can be referenced by an Ingress's `tls` section or mounted into a pod for TLS termination.

The container is OOMKilled because it exceeds the memory limit. Memory limits are enforced via a cgroup; when the container's memory usage surpasses that limit, the kernel's OOM killer terminates the offending process. This results in the pod's container being marked as OOMKilled with exit code 137, and Kubernetes restarts it according to the restart policy.

Init containers are always started before any application containers in the pod. Each init container must run to completion successfully before the next one is launched, and if one fails, Kubernetes applies the pod's restartPolicy to determine whether to restart it; only after all init containers succeed does the kubelet start the main app containers.

Set fsGroup: 2000 in the pod-level securityContext - This ensures the volume files' group ownership is changed to 2000 and the container process is part of that supplementary group, allowing read access. This is the correct approach.

This is the correct syntax because `kubectl create secret generic` creates an Opaque Secret, and each `--from-literal` flag adds one key-value pair directly from the command line. kubectl automatically Base64-encodes the specified values when storing them in the Secret's `data` field, so `username=admin` and `password=secret123` become the secret's data entries. This approach is ideal for simple credential pairs without needing any local files.

The --from-file flag tells kubectl to read the contents of the specified file and create a single data key in the ConfigMap, using the filename (app.properties) as the key and the file's content as the value. This is the correct imperative way to generate a ConfigMap from a file without manually writing a YAML manifest. Because the content becomes the value, any valid file format (properties, JSON, YAML, or plain text) can be stored as an opaque data entry.

Without a readiness probe, kube-proxy considers a Pod 'Ready' as soon as its containers are running, even if the application inside is still initializing, warming up, or temporarily unable to handle traffic. This causes the Service to include such Pods as endpoints, so some requests get routed to a Pod that will sporadically return 5xx errors or drop the connection. A readiness probe solves this by marking the Pod Ready only when it responds successfully to a health check, ensuring the Service’s endpoint list contains only truly available Pods.

The correct command is 'kubectl run nginx --image=nginx:1.25'. This is the standard imperative command for creating a single Pod: it generates a Pod object named 'nginx' with the specified container image and submits it to the cluster. 'kubectl run' is specifically designed for this purpose, whereas 'kubectl create' and 'kubectl apply' have different roles.

schedule is mandatory because it defines the cron expression that tells the CronJob controller when to create a new Job. Without this value, the controller has no time-based trigger, and the Kubernetes API server will reject the manifest as invalid. The expression uses the standard five-field cron format, for example '*/30 * * * *' for every thirty minutes.

The correct purpose is to exclude files and directories from the build context that the Docker client sends to the Docker daemon, shrinking the upload size and preventing sensitive or irrelevant data from reaching layer builds. Any path listed in .dockerignore is absent from the context, meaning COPY/ADD cannot access those files at all, and changes to them won't invalidate the build cache. This is the intended, documented behavior of the file.

`spec.strategy.rollingUpdate.maxSurge` is the correct field because it directly controls the maximum number of pods that can be created above the desired `replicas` value during a rolling update. It allows the Deployment to temporarily overshoot the steady-state replica count to ensure new pods become ready before old ones are terminated, thereby maintaining capacity. For example, `maxSurge: 1` permits one extra pod beyond the desired count, while `maxSurge: 25%` allows a percentage-based overshoot.

Opaque is the default Kubernetes Secret type when no `type` field is specified, designed for arbitrary key-value pairs such as passwords, API tokens, or configuration fragments. Its data is base64-encoded but not encrypted at rest by default, and no additional validation or controller behavior is attached to it. This makes it the general-purpose fallback for most application secrets, and it is the most commonly used type in practice.

runAsNonRoot instructs the kubelet to verify that the container's effective user is not UID 0 before starting it. When the container image specifies root as its user, the kubelet returns an error and refuses to start the container, leaving the Pod in a failed or Pending state with a container creation failure event. This prevents a root process from ever executing.

Liveness probe is a standard Kubernetes probe type that checks the health of a running container and restarts it if the probe fails. It helps recover from deadlocks or stuck processes where the container is still running but no longer functioning correctly. When a liveness probe fails, the kubelet kills the container and replaces it according to the pod's restart policy, enabling self-healing applications.

At least one rule specifying either a host or path is essential because the Ingress resource is fundamentally a routing table; without a rule, there is no destination for incoming traffic. Each rule defines a mapping from an HTTP host and/or URL path to a backend service, and this mapping is what the controller uses to proxy requests. A bare Ingress with no rules would be inert and could not route anything.

parallelism specifies the maximum number of Job Pods that can run simultaneously. It does not define the total number of Pods; it only sets the concurrency cap for the Job. For a non-parallel Job, parallelism is implicitly 1, but for a parallel Job, you can set it higher to process multiple work items at once. This field is useful for controlling resource usage and throttling the rate at which work is processed.

The --from-literal flag creates a single key-value entry directly from the command line, using the exact syntax key=value. It is the simplest way to inject a scalar value, and you can repeat the flag multiple times to add more entries. Each flag must be a valid key-value pair, and the key must follow Kubernetes naming conventions (alphanumeric, '-', '_', '.').

This is the correct command because `kubectl create secret tls` is the dedicated subcommand for generating a Kubernetes secret of type `kubernetes.io/tls`. It requires the `--cert` flag to point to the PEM-encoded certificate (usually the full chain) and the `--key` flag to point to the PEM-encoded private key. The resulting secret automatically stores these under the standard data keys `tls.crt` and `tls.key`, which ingress controllers and other TLS consumers expect. Using this exact syntax ensures the secret is properly typed and immediately usable for TLS termination.

This is the correct approach because a startup probe gives the kubelet an explicit phase for container initialization. While the startup probe is failing, liveness and readiness probes are not executed at all; only after the startup probe succeeds do the steady-state probes take over. By configuring a sufficient failureThreshold and periodSeconds, you define the maximum startup window (failureThreshold * periodSeconds) during which the container is allowed to initialize without being killed. This is the canonical pattern for slow-starting containers, as it avoids guessing an exact initialDelaySeconds and automatically adapts to the container's actual startup behavior, then hands off to normal liveness checking.

The `kubectl rollout history deployment app` command is the dedicated subcommand that displays the rollout history for a Deployment, showing an ordered list of revisions, each with its revision number and, if specified, the change cause from the `kubernetes.io/change-cause` annotation. This output directly reveals how the Deployment has evolved over time, making it the correct choice for viewing rollout history. Additionally, you can use the `--revision` flag to inspect a specific historical revision's detailed configuration.

In the PodSecurityContext, runAsUser specifies the UID that all containers in the pod run with, overriding any image-level USER directive. It is a pod-level field because it belongs to the pod's security context and applies uniformly to every container's primary process. Setting it ensures consistent privilege separation at the pod level.

This is a valid use case for HPA, implemented through custom metrics. By exposing HTTP request counters from the application (e.g., via Prometheus) and registering a custom metrics adapter, HPA can query a metric like `http_requests_per_second` and scale replicas proportionally. The `autoscaling/v2` API allows referencing this custom metric via the `type: Object` or `type: Pods` metric source, making request-driven scaling a common real-world pattern.

This is the valid schedule for every 5 minutes: the minute field uses the */5 step syntax, meaning the job fires at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55. All remaining fields (hour, day of month, month, day of week) are wildcards, so no further restriction is applied. With no seconds field, standard cron has a minute resolution.

The correct value is 1 because maxSurge is defined as the number of additional pods that can be created above the desired replica count during a rolling update. Setting maxSurge=1 means that while updating, the deployment may temporarily run one extra pod beyond the desired replicas, ensuring that new pods are available before old ones are terminated, thereby maintaining service availability without exceeding a small, controlled increase in resources.

`kubectl apply -k overlays/production/` is the correct declarative approach because the `-k` flag tells kubectl to treat the directory as a kustomization root, build the resource set defined in `kustomization.yaml`, and send the resulting resources to the API server for apply. It is a single command that natively leverages the kustomize build process inside kubectl, exactly matching the requirement to use kustomize to patch a deployment. This is the canonical way to apply an overlay in modern kubectl without extra tools or piping.

`helm upgrade --dry-run` is the right choice because it previews the exact changes that an upgrade to `my-release` would apply by rendering the new templates and performing a three-way merge between the last release manifest, the live cluster state, and the desired chart output. It shows a diff of what will be created, updated, or deleted—without actually touching the cluster—so you can catch template errors, missing values, or resource conflicts. Unlike `install`, this command targets the existing release, making it the standard tool for safe upgrade validation.

This is the correct liveness probe because it declares an httpGet handler that instructs the kubelet to send an HTTP GET request to the container's /healthz endpoint on port 8080. Kubernetes considers the probe successful if the HTTP response status code is in the 200-399 range, so a 400 or 500 response would restart the container. This definition precisely matches the stated requirement of performing a HTTP GET liveness check against that path and port.

Once all init containers have exited successfully, Kubernetes proceeds to start the main application container. From that point, the pod's restartPolicy (Always, in this case) governs the main container: any failure or non-zero exit triggers a restart by the kubelet, possibly with an exponential backoff. The init container will not be re-executed when the main container restarts, so the pod remains active until the main container exits cleanly.

kubectl port-forward pod/pod-name 8080:8080 creates a local TCP listener on the specified host port (8080) and tunnels that traffic over the Kubernetes API server to port 8080 of the named pod. This makes the pod's application available at localhost:8080, which is exactly what the developer needs for direct access to a single pod. It is ephemeral and client-side; no Service or Ingress object is created, and the tunnel disappears when the command is terminated.

The batch API group manages job-like workloads, and batch/v1 is its stable version, available since Kubernetes 1.21. This version supersedes batch/v1beta1 and is the correct choice for Jobs, supporting features such as ttlSecondsAfterFinished, parallelism, and completions. Always specify batch/v1 for Jobs to ensure compatibility with current and future cluster versions.

runAsUser is a valid container-level SecurityContext field that specifies the user ID for the container's primary process. When set at the container level, it overrides any runAsUser value defined at the Pod level. This is essential for ensuring containers run as a non-root user, reducing the risk of privilege escalation.

spec.containers[].ports[].hostPort is valid because it explicitly maps a container port to a port on the host node's network interface, enabling external traffic to reach the container via the node's IP without requiring a separate Service object. This field must be nested inside a port entry, alongside containerPort, and comes with operational caveats such as port conflicts and node scheduling constraints.

The policy spec uses an empty podSelector, which selects all pods in the namespace as the destination of traffic. Its ingress rule contains a from podSelector matching any pod labeled 'role: frontend', so those sources are explicitly allowed to initiate connections to every pod selected by the policy. Since no egress rules or policyTypes are set, only inbound traffic is controlled and only from that source label.

This statement is true because the Ingress spec includes a `host` field in each rule, allowing you to route requests based on the requested domain name. For example, you can direct `app.example.com` to one Service and `admin.example.com` to another, even within the same Ingress resource. This enables host-based virtual hosting, a standard feature of HTTP routing.

When a Secret volume is mounted, each Secret key becomes a file in the mount path, and its contents are the decoded value exactly as you supplied it. Kubernetes performs this decode from the stored base64 form before writing to the volume, so the raw `myPass` is what an application sees when reading the file. This functionality is a core feature for injecting configuration data into Pods.

fsGroup 2000 sets the mounted volume's group ownership and permissions, so the volume is owned by group 2000, while runAsGroup 3000 governs the container process's primary group. The volume's user ownership comes from runAsUser 1000. These are distinct axes, which is why the volume group and process group differ.

A sidecar container is an auxiliary process that deploys alongside the main container to provide supporting functionality without being the primary workload. Common use cases include collecting and shipping logs (e.g., Fluentd), acting as a service mesh proxy (e.g., Envoy), or synchronizing data volumes between local and remote storage. This pattern encapsulates cross-cutting concerns into a separate, co-located process that shares the Pod's lifecycle.

kubectl get pod app -o yaml is correct because it directly retrieves the live Pod object from the Kubernetes API server and serializes it into YAML, printing the full definition to stdout. This output includes the complete metadata, spec, status, and other fields such as resourceVersion and managedFields, giving you the exact current state of the Pod as known by the cluster. It is the canonical read-only command for viewing a resource's YAML manifest, and unlike editing, it does not require interaction or risk unintended modifications.

FROM is the only instruction that identifies the base image for a build, either by pulling a tag from a registry (e.g., node:20-alpine) or by referencing a previous build stage by name (e.g., FROM builder AS runtime). This instruction initializes a new build stage and establishes the filesystem, default environment, and runtime libraries that subsequent instructions inherit. Without a valid FROM, Docker will reject the Dockerfile as having no base layer.

An Ingress resource is the correct approach because it manages external HTTP(S) access to services using hostnames and URL paths, and it is backed by an ingress controller that typically provisions a stable external IP or load balancer. This gives clients a single, predictable address to reach the deployment, while also supporting TLS termination and advanced routing rules without creating multiple NodePorts.

--from-env-file=app.env specifically parses a file containing lines in KEY=VALUE format and creates a separate data entry for each line. This is the intended way to import an environment file into a ConfigMap, preserving each variable as its own key-value pair.

The command `kubectl exec pod-name -- ls -la /data` is correct because it instructs kubectl to run the `ls -la /data` process inside the first container of the existing pod `pod-name`. The `--` separates kubectl's local flags from the remote command to be executed, ensuring that arguments like `-la` are passed to `ls` rather than being interpreted by kubectl. This is the canonical method for executing ad-hoc commands in a running pod's container.

The correct scale-down timing is 300 seconds because the HorizontalPodAutoscaler always applies the scale-down stabilization window before reducing replicas. This window, defaulting to 300 seconds, prevents the controller from reacting to short-lived CPU drops that might be transient, ensuring that the number of pods is only decreased after the low utilization is consistently observed. Once the stabilization window has passed, the HPA reevaluates the desired replica count and performs the scale-down.

The kubectl rollout undo deployment <name> command reverts a Deployment to its previous revision by scaling down the current ReplicaSet and scaling up the prior ReplicaSet according to the stored rollout history. This updates the pod template to the old spec, effectively reversing the changes made by the rolling update. Use --to-revision to target a specific revision, otherwise it selects the last available revision.

Setting behavior.scaleDown.stabilizationWindowSeconds configures the HPA to remember the desired replica counts from the last N seconds and, when scaling down, to use the maximum of those historical values instead of the newest recommendation. This creates the cooldown effect: after CPU utilization falls, the controller will not immediately shrink to the new lower desired count; it will only step down once the higher value ages out of the window. This prevents rapid, oscillating scale-downs during transient load dips and is exactly the field needed to avoid premature replica reduction.

NET_ADMIN is the Kubernetes name for the Linux capability CAP_NET_ADMIN, which permits operations such as configuring network interfaces, modifying routing tables, and managing firewall rules. It is a legitimate capability that can be added to a container's security context, making it one of the three correct answers.

The container is being OOMKilled because its memory usage exceeds the current limit, triggering the kernel OOM killer. Raising the limit to 512Mi provides sufficient headroom for the container's observed usage, allowing the process to continue running. This is only safe if the node has enough allocatable memory to accommodate the new limit.

Empty podSelector targets all pods; no ingress rules means deny all ingress.

This is the correct definition. The maxUnavailable field in a Deployment's rolling update strategy sets the maximum number of Pods that can be unavailable relative to the desired replicas during the update process. It guarantees that a sufficient number of Pods remain running to serve traffic, with the default of 25% ensuring at least 75% availability.

This is the correct answer because a Kubernetes secret of type `kubernetes.io/tls` conventionally uses exactly these two data keys: `tls.crt` holds the PEM-encoded server certificate (and optionally an intermediate chain), and `tls.key` holds the PEM-encoded private key. When an Ingress resource specifies a TLS block with `secretName`, the controller loads these keys to terminate HTTPS for the configured host. The presence of both correctly named keys, along with a matched certificate/key pair, enables a valid TLS termination setup.

Correct because maxSurge: 5 allows up to 5 extra pods, and maxUnavailable: 2 allows up to 2 unavailable, matching the requirement.

This is the correct field in the `securityContext` (either at pod or container level) to specify a seccomp profile that restricts system calls. By setting `type: RuntimeDefault`, you tell the container runtime (e.g., containerd, CRI-O) to use its default seccomp profile, which blocks a set of dangerous or unused syscalls. For custom filters, you can point to a `Localhost` profile using the `localhostProfile` field and a node's profile directory. This directly satisfies the requirement of running with a seccomp profile.

The --previous flag instructs kubectl to fetch the log file from the last container instance that terminated, which is exactly the data you need when the current container was restarted due to a crash. This works even if the current container is now running, as long as a previous instance exists; if the pod has multiple containers, you must add -c <container-name> to target the right one.

This is the correct approach. secretKeyRef directly references the Secret object by name ('mysecret') and extracts the specific key ('password') from that Secret's data. When this env var is defined, Kubernetes fetches the decoded value of the 'password' key and injects it into the container's SECRET_DATA environment variable, fulfilling the requirement to mount the secret as an environment variable.

The `kubernetes.io/tls` Secret type is a built-in type designed specifically to store a TLS certificate and its associated private key. The data keys must be named exactly `tls.crt` for the certificate and `tls.key` for the private key; when mounted or referenced by an Ingress, the API server uses these keys to configure HTTPS termination. It is the standard type for any TLS secret, and its structure is enforced by Kubernetes controllers for Ingress and other TLS consumers.

kubectl scale deployment nginx --replicas=5 is the correct command because the scale subcommand directly adjusts the desired replica count for a Deployment, updating spec.replicas in the live object. It also accepts optional flags like --current-replicas to perform optimistic concurrency checks and --timeout to wait for the scale operation to complete. This is the standard imperative way to resize a Deployment's pod count in Kubernetes.

Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, so even a compromised process cannot modify binaries, libraries, or write new files to the container layer. Any legitimate writes must go to explicitly mounted writable volumes, which sharply limits the blast radius of an attack. This is a strong defense-in-depth control that complements other securityContext settings.

journalctl -u kubelet is correct because on systemd-based Linux distributions, the kubelet is managed as a systemd service, and its stdout, stderr, and syslog messages are captured by the journal daemon. Running this command on the affected node retrieves the complete, timestamped log stream from that unit, revealing startup errors, connection failures, or config file issues. This is the standard method to inspect kubelet logs for diagnosing why a node is NotReady.

kubectl describe pod <pod> displays the pod's full status, including the volume list, associated PVCs, container states, and crucially the Events section at the bottom. If the pod is stuck in ContainerCreating, the kubelet emits a FailedMount event with a message such as "unable to find storage class" or "no persistent volumes available for this claim," which directly identifies the missing storage class. This event is the authoritative source for the reason the pod cannot start, and the output also shows current conditions and volume definitions for a complete diagnostic picture.

When you run kubectl rollout undo with no flags, Kubernetes automatically selects the last available revision from the workload's rollout history and applies that configuration to replace the current pod template. This is a single-step revert that undoes only the most recent change, leaving older revisions untouched. If you need to return to an earlier state, you must explicitly specify --to-revision.

The parallelism field in a Job spec directly sets the maximum number of pods that can run at the same time. With parallelism=2, the Job controller ensures no more than 2 pods are active concurrently, regardless of the completions count being 5.

ClusterIP is the default service type when no `spec.type` is specified. It assigns the Service a stable virtual IP reachable only within the cluster, allowing pods to discover and route to the Service's endpoints via kube-proxy and DNS. This internal-facing default provides load balancing across pods without exposing traffic externally.

The Pod Security Admission controller supports three operational modes: enforce, warn, and audit. Enforce rejects violating pods at creation time, while warn and audit only record warnings or log audit events without blocking the pod. This allows cluster operators to test policies incrementally before enabling strict enforcement.

VOLUME is the correct Dockerfile instruction because it explicitly creates a mount point and marks it as a location for external storage volumes. When a container is run, Docker automatically creates an anonymous volume at that path unless a named volume or bind mount is supplied via the run command or compose file. This instruction is essential for defining persistent data locations, as it tells Docker that the specified directory should be preserved independently of the container's writable layer and can be shared between containers.

`kubectl top pod` is the only command here that talks to the Kubernetes Metrics API, which the Metrics Server populates by scraping kubelet's cAdvisor endpoint. It prints the actual instantaneous CPU and memory utilization per container, e.g., `100m` and `120Mi`, giving you a direct view of live usage. That exactly matches the task of checking the pod's CPU and memory usage.

COPY --from=builder /app/artifact /app/ is the standard multi-stage mechanism: it tells the current build stage to take the file or directory at /app/artifact from the stage named builder and place it at /app in the new image layer. This instruction is explicit about the source stage, avoids ADD's archive-extraction side effects, and lets you keep build-only tools out of the final runtime image. The artifact is copied directly from the builder stage's filesystem into the next stage's filesystem.