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

.dockerignore excludes files from the build context, reducing build time and preventing secrets from being copied.

'kubectl rollout pause deployment/myapp' pauses the rollout. 'kubectl set image ... && kubectl rollout pause' pauses after setting the image but before the rollout completes. 'kubectl rollout resume' resumes, not pauses.

An Ingress controller (like NGINX or other) with traffic splitting capabilities (e.g., via annotations or canary config) can distribute traffic between services. Alternatively, a Service Mesh like Istio can be used, but Ingress is the most common standard resource.

A Service of type ClusterIP or NodePort is required because the Ingress resource routes external HTTP traffic to a Service, which then forwards it to the Pods. ClusterIP is the default and most common type for internal cluster routing, while NodePort can also be used but is less typical. Without a Service, the Ingress has no endpoint to direct traffic to.

In HPA v2 (autoscaling/v2), the spec includes 'metrics', 'behavior', and 'minReplicas'. 'metrics' defines the metrics to scale on, 'behavior' defines scaling policies, and 'minReplicas' sets the minimum number of pods. 'targetCPUUtilizationPercentage' is a deprecated field from v1. 'scaleTargetRef' is a required field but is not listed among the options as a field of spec; it's a separate field in the spec.

Option D is correct because Kubernetes DNS resolves services across namespaces using the format `<service>.<namespace>.svc.cluster.local`. When a Pod in one namespace needs to communicate with a service in another namespace, the fully qualified domain name (FQDN) must include the namespace to disambiguate the service. This is defined by the Kubernetes DNS specification, which appends `svc.cluster.local` as the cluster domain suffix.

The error message explicitly states 'requested: pods=1, used: pods=5, limited: pods=5'. This means the ResourceQuota named 'compute-quota' has a hard limit of 5 pods in the namespace, and that limit has already been reached. The Pod creation fails because the quota's `count/pods` scope is exhausted, not because of resource requests or permissions.

The 'Back-off restarting failed container' event indicates that the container process exits immediately after starting, causing Kubernetes to repeatedly restart it with increasing back-off delays. This is most commonly caused by a container entrypoint or command that fails at runtime, such as a misconfigured binary, missing dependency, or incorrect startup script. Unlike probe failures, which cause restarts after the container is already running, this error occurs before the container can even become ready.

A tcpSocket probe is the correct choice when you need to verify that a container is listening on a specific TCP port, such as port 8080. It works by attempting to open a TCP connection to the specified port; if the connection succeeds, the probe is considered successful. This is ideal for checking basic network-level readiness or liveness without requiring an HTTP endpoint or a custom command.

Startup probes are a valid Kubernetes probe type used to determine when a container application has started successfully. They are particularly useful for legacy applications that have slow startup times, as they delay the start of liveness and readiness probes until the startup probe succeeds, preventing premature container restarts.

A failing readiness probe causes the pod to be removed from the Service's endpoints, so it will not receive traffic. The pod continues running and can be restarted by a liveness probe if configured, but readiness only affects traffic routing.

A sidecar container that enhances the primary container (e.g., log shipper) is a classic sidecar pattern.

kubectl debug with the -it flag creates an ephemeral container for debugging. Option A is correct.

By increasing the number of replicas in the v2 Deployment, more pods will be available to receive traffic from the Service, as both versions share the same label.

When a pod has both an `envFrom` referencing a ConfigMap and an explicit `env` entry with the same key, the explicit `env` entry takes precedence. This is because Kubernetes merges environment variables from multiple sources, and individual `env` entries override any values from `envFrom` for the same key. Therefore, `APP_DEBUG` will be set to 'false' as defined in the explicit `env` entry.

When a ResourceQuota is applied to a namespace with a memory request limit of 2Gi, any pod creation that would cause the total memory requests in the namespace to exceed that quota is rejected by the Kubernetes API server. The pod creation fails immediately with an error message indicating the quota would be exceeded, because the admission controller validates the request against the quota before allowing the pod to be scheduled.

Setting `seccompProfile.type: RuntimeDefault` in the Pod's securityContext instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile to the container. This default profile restricts system calls to a safe subset, blocking dangerous or unnecessary syscalls while allowing common ones required for typical application execution. It is the recommended way to enable seccomp without managing a custom profile.

A Service in Kubernetes provides a stable DNS name (via cluster DNS, e.g., CoreDNS) that resolves to the Service's ClusterIP, and it load-balances traffic across the pods selected by its label selector using iptables or IPVS rules. This directly fulfills the requirement for both service discovery and load balancing within the cluster.

The pod cannot be scheduled because the requested CPU is not available on any node. Reducing the CPU request may allow scheduling.

The 'kubectl run' command without '--restart=Never' defaults to a Deployment (apps/v1), but with '--restart=Never' it creates a standalone Pod (v1).

The '-f' flag (follow) allows you to stream logs in real-time.

The pod is rejected because the ResourceQuota in namespace 'team-a' sets a hard limit of 8 CPUs for limits.cpu across all pods. The developer's pod specifies a limit of 10 CPUs, which exceeds this quota. Kubernetes enforces ResourceQuota at admission time, so any resource request or limit that violates the quota's constraints will cause the pod creation to be denied.

These are critical fields in a Deployment YAML.

Option B is correct because if the ConfigMap does not exist in the namespace, any pod referencing it will fail to start or the application will be unable to read the configuration data. Kubernetes validates ConfigMap existence at pod creation time, and missing ConfigMaps cause the pod to remain in a pending state or the application to log errors like 'missing key' when attempting to access the configuration.

ClusterIP is default, Services can have multiple ports, and NodePorts are allocated from a range (default 30000-32767).

A readiness probe determines if a pod is ready to receive traffic. If it fails, the pod is removed from the Service endpoints, but it continues running.

The 'parallelism' field specifies how many pods can run concurrently. 'completions' is for total successful pod completions.

StatefulSets require headless services (clusterIP: None) to provide stable DNS names for each pod (e.g., mysql-0.mysql.default.svc.cluster.local).

Endpoints can be viewed via 'kubectl get endpoints my-svc' and 'kubectl describe svc my-svc' shows endpoint information.

Helm install with a chart reference installs a chart. Option B is correct.

Option B is correct because `initialDelaySeconds` is a valid field in a Kubernetes probe configuration (liveness, readiness, or startup probe). It specifies the number of seconds to wait after the container starts before initiating the first probe, allowing the application to initialize before being checked.

The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

ENTRYPOINT sets the main command that will always be executed when the container starts.

Option D is correct because increasing the failureThreshold to 10 and periodSeconds to 10 gives the readiness probe more time (100 seconds total) to tolerate transient slowness on the /healthz endpoint, preventing premature removal of Pod IPs from the Endpoints object. This keeps all backend Pods in the ready state during response time spikes, ensuring the Service remains reachable.

For a Secret of type `kubernetes.io/tls`, the Kubernetes API server expects the data to contain exactly the keys `tls.crt` and `tls.key`. When such a Secret is mounted as a volume into a pod, the files created in the mount path are named `tls.crt` and `tls.key`, matching these keys. This is enforced by the Kubernetes TLS secret controller and is documented in the official Kubernetes reference for TLS secrets.

The ExternalName Service type maps a cluster-local DNS name (e.g., `my-db.default.svc.cluster.local`) to an external DNS name (`db.example.com`) using a CNAME record. This allows Pods to resolve the service name to the external database address without needing to modify application code or use an external endpoint.

In Kubernetes v1.29, the correct apiVersion for a CronJob is batch/v1, as CronJob has been stable since v1.21. Option D is correct because batch/v1 is the stable API version for CronJob resources in this release.

The 'restricted' Pod Security Admission (PSA) policy enforces the most stringent security controls, requiring pods to meet specific baseline security constraints. Option A satisfies these requirements by setting `runAsNonRoot: true` (preventing root execution) and `readOnlyRootFilesystem: true` (preventing writes to the root filesystem), both of which are mandatory for the restricted profile. The other options violate the restricted policy by either enabling privileged access, adding dangerous capabilities, or omitting required security contexts.

HPA can scale based on custom metrics like requests per second or queue length, not just CPU/memory.

NodePort exposes the Service on a port on each node's IP address, accessible from outside the cluster.

Both `kubectl expose` and creating a YAML manifest are valid methods.

Option A is correct. The TLS configuration in an Ingress includes a 'secretName' field in the 'tls' array that references a secret in the same namespace.

Option A is correct because the `valueFrom.secretKeyRef` field in a container's `env` definition directly references a specific key from a Kubernetes Secret and injects its value as an environment variable. This is the standard method for exposing a single secret key as an environment variable, as defined in the Kubernetes API.

This policy selects all pods (empty podSelector) and denies all ingress and egress traffic by default because no rules are specified. It does not affect traffic that is not covered by policyTypes, but since both are selected, all inbound and outbound traffic is denied for all pods in the namespace.

Option C is correct because when a ConfigMap is mounted using `subPath`, Kubernetes treats the mount as a single file rather than a directory of symlinks. This means the atomic update mechanism (which uses symlinks to swap the directory contents) is bypassed, and updates to the ConfigMap are not reflected in the Pod without a restart or remount.

Prefix matching matches any path starting with /api, so /api/v1/users matches.

NetworkPolicy is namespace-scoped. Default is to allow all traffic if no policy selects the pod. An egress rule can restrict outbound traffic to specific IPs (ipBlock).

Deployment first, then define NodePort Service, apply, retrieve port, then access externally.

A is correct because Kubernetes Secrets are designed to be consumed by Pods either as files mounted into a volume (via `volumes` and `volumeMounts`) or as environment variables (via `env` or `envFrom`). This flexibility allows applications to access sensitive data like passwords or tokens without hardcoding them into the container image or pod spec.

Init containers run to completion before app containers start, used for setup tasks like waiting for dependencies or preparing data.

Endpoints are created by the Service based on the selector. If no pods match the selector, the endpoints list will be empty. The solution is to check the pod labels.

values.yaml contains default configuration values that can be overridden during installation or upgrade.

Option B is correct because the `EXPOSE` instruction in a Dockerfile informs Docker that the container listens on the specified network port at runtime. It is a metadata declaration that does not actually publish the port; it serves documentation and inter-container communication purposes via Docker networks.

The standard DNS name for a Service is <service>.<namespace>.svc.cluster.local.

The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.