Practice Exam

C) Deployment. Deployments manage rolling updates, gradually replacing old Pods with new ones. StatefulSets provide stable identities (not needed for stateless inference). DaemonSets run one Pod per node. ReplicaSets do not support rolling updates natively.

D) All of the above are useful. kubectl logs --previous shows logs from the crashed container. kubectl describe pod shows events, restart reasons, and status. kubectl get events shows namespace-level events. In the CKA, use all three for comprehensive troubleshooting.

B) ResourceQuota. ResourceQuota limits aggregate resource consumption per namespace. LimitRange sets per-Pod or per-container defaults and maximums. PodDisruptionBudget controls voluntary disruptions. HPA scales replicas based on metrics.

B) Running normally. The container is using 6Gi, which is above the request (4Gi) but below the limit (8Gi). Memory requests are used for scheduling (guaranteed minimum), while limits are the maximum. The container runs normally as long as it stays below the limit. It would be OOMKilled only if it exceeds 8Gi.

B) Secret. Secrets are designed for sensitive data (passwords, API keys, tokens). They are base64-encoded and can be mounted as volumes or exposed as environment variables. ConfigMaps are for non-sensitive configuration. Note: Kubernetes Secrets are not encrypted by default — enable encryption at rest for production clusters.

B) The Pod remains Pending. A Pod is always scheduled on a single node. Since no node has 5 GPUs, the Pod cannot be scheduled and stays in Pending state. Kubernetes does not split a Pod across nodes. To use more than 4 GPUs, you need distributed training with multiple Pods.

B) The web server Pods remain Pending (assuming only GPU nodes exist). With the NoSchedule taint, Pods without a matching toleration cannot be scheduled on those nodes. If non-GPU nodes exist, the Pods would be scheduled there instead. If only GPU nodes exist, they stay Pending.

C) DaemonSet. A DaemonSet ensures exactly one Pod runs on each node (or a subset of nodes). The NVIDIA device plugin runs as a DaemonSet so it discovers and registers GPUs on every GPU-equipped node in the cluster.

B) preferredDuringSchedulingIgnoredDuringExecution. The preferred affinity is a soft constraint — the scheduler tries to place the Pod on matching nodes but falls back to other nodes if none are available. required is a hard constraint that would leave the Pod Pending if no A100 nodes exist.

D) Any of the above could be the cause. The GPU stack requires: (1) NVIDIA drivers installed on the host, (2) NVIDIA Container Toolkit for GPU passthrough to containers, (3) a running device plugin Pod. If any layer fails, GPUs will not appear as allocatable resources. Check nvidia-smi on the node, verify the container runtime config, and check device plugin Pod logs.

B) Forbid. With Forbid, if the previous Job is still running, the CronJob skips the new run. Allow creates both (concurrent runs). Replace kills the running Job and starts a new one. Skip is not a valid option.

B) The Job is marked as Failed. With backoffLimit: 3, the Job allows 3 retries (for a total of 4 attempts including the original). After 4 failures, the Job transitions to a Failed state and no more Pods are created.

B) The Pod does not receive traffic from the Service. During the initialDelaySeconds period, the readiness probe has not been checked yet, so the Pod is considered not ready. The Service does not route traffic to non-ready Pods. This gives the model time to load into memory before receiving requests.

B) Init container. Init containers run before the main containers and must complete successfully before the main containers start. They are perfect for setup tasks like downloading data, populating volumes, or waiting for dependencies. Sidecar containers run alongside the main container (not before).

A) Scale down to 2 replicas. The desired replicas formula is: ceil(currentReplicas x (currentUtilization / targetUtilization)) = ceil(4 x (35/70)) = ceil(4 x 0.5) = ceil(2) = 2. Since 2 equals the minReplicas, the HPA scales down to 2 replicas.

A) Yes, emptyDir survives Pod restarts. An emptyDir volume's lifetime is tied to the Pod, not the container. When a container crashes and is restarted within the same Pod, the emptyDir data persists. However, if the Pod is deleted (and rescheduled as a new Pod), the emptyDir is lost. For important checkpoints, use PersistentVolumeClaims.

B) The second Pod stays Pending. ReadWriteOnce (RWO) means the volume can only be mounted by a single node. Since Node A already has it mounted, the second Pod on Node B cannot mount it and remains Pending. If the second Pod were on Node A, it could potentially mount it (RWO is per-node, not per-Pod, in practice).

B) One (with multiple path rules). A single Ingress resource can define multiple path rules under the same host, each routing to different backend Services. TLS configuration is also included in the same Ingress resource under the tls section.

B) All ingress traffic to all Pods in the namespace is denied. An empty podSelector selects all Pods in the namespace. A policy with policyTypes: ["Ingress"] and no ingress rules means "select all Pods and deny all incoming traffic." This is the default-deny pattern commonly used as a baseline security policy.

B) When a Pod that uses the PVC is scheduled. WaitForFirstConsumer delays volume provisioning until a Pod that references the PVC is scheduled. This ensures the volume is created in the same availability zone as the Pod. With Immediate (default), the volume is created as soon as the PVC is created, which may cause scheduling issues if the volume is in a different zone.