DOP-C02 Resilient Cloud Solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Configure a pod disruption budget to prevent too many pods from being terminated simultaneously.

  Why it's wrong here

  Pod disruption budgets (PDBs) only constrain voluntary disruptions such as cluster-admin node drains, where you explicitly evict pods with an Eviction API. They have no effect on involuntary failures like an EC2 instance or node crashing, because PDBs do not prevent Kubernetes from deleting pods when the node is unreachable. Configuring a PDB alone does not trigger replacement of an unhealthy node or rescheduling of its pods.

• ✗

  Use a horizontal pod autoscaler to increase the number of pods during high load.

  Why it's wrong here

  The horizontal pod autoscaler (HPA) adjusts the number of replicas based on observed metrics such as CPU and memory utilization, not on node health. If a node fails, the HPA cannot detect the failure and will not move pods from that node; in fact, it might continue scaling up replicas that are scheduled onto the remaining unhealthy capacity, worsening the situation. Node failures require a separate mechanism for detecting and replacing the infrastructure, not an HPA.

• ✓

  Configure the EKS managed node group with a health check and ensure that the Kubernetes control plane automatically reschedules pods from failed nodes.

  Why this is correct

  An EKS managed node group is backed by an Auto Scaling group whose health checks include both Amazon EC2 status checks and Kubernetes node status (including the node-lost and NodeReady conditions). When a node fails or becomes unhealthy, the Auto Scaling group replaces the underlying instance, while Kubernetes' node controller marks the node as NotReady and evicts pods, leading them to be rescheduled onto healthy nodes. This combination of automatic instance replacement and control-plane-driven pod rescheduling directly addresses the failure of a node and is the expected solution for maintaining availability.

• ✗

  Use a cluster autoscaler to automatically add new nodes when pods are pending.

  Why it's wrong here

  The cluster autoscaler reacts to unschedulable pods by provisioning additional nodes, but it does not initiate the rescheduling of pods from an existing failed node. When a node fails, Kubernetes must first mark it as NotReady and evict or delete its pods; only then can the cluster autoscaler scale out for any pending pods. Relying only on the cluster autoscaler would delay failover because it does not perform health checks or replace the failed node itself, and it also cannot determine whether the failed node's pods are the actual reason for capacity shortage.

Go deeper

Related to this question