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.

• ✗

  Change the service type from ClusterIP to NodePort and configure an external load balancer.

  Why it's wrong here

  Converting the Service from ClusterIP to NodePort and placing an external load balancer in front only changes the ingress path; it does not alter the Deployment's replica count, scheduling, or failure-domain spread. The load balancer still forwards traffic to whatever endpoints the Service discovers, so if all Pods are colocated and the node (or availability zone) hosting them fails, the Service will have no healthy endpoints and the load balancer returns 503s. It also provides no protection against voluntary disruptions like a node drain.

• ✗

  Increase the number of replicas to 10 and use a node selector to schedule all pods on the largest instance type.

  Why it's wrong here

  Adding replicas to 10 is redundant, and a node selector that forces every Pod onto the largest instance type actually creates a tighter coupling to a single infrastructure dependency. If the cluster only has one node matching that label, or the scheduler packs all replicas onto one big node, that node becoming unhealthy takes the entire application down in one event. Without pod anti-affinity or topology-spread constraints, the scheduler is free to place all replicas in the same failure domain, and the extra replicas provide no additional resilience.

• ✓

  Configure a PodDisruptionBudget with a maxUnavailable of 1, and add pod anti-affinity rules to spread pods across different nodes.

  Why this is correct

  A PodDisruptionBudget with maxUnavailable:1 guarantees that at most one Pod is unavailable during voluntary evictions such as node drains, and pod anti-affinity rules (preferably with topologyKey kubernetes.io/hostname) force the scheduler to place replicas on distinct nodes. This means an involuntary node failure can kill only one replica, and the remaining replicas continue to serve traffic. Combined, these mechanisms directly address both failure classes—involuntary hardware failures and voluntary maintenance—by ensuring the application always has at least N-1 replicas available across different failure domains.

• ✗

  Enable HorizontalPodAutoscaler with a target CPU utilization of 50% to automatically scale the Deployment.

  Why it's wrong here

  The HorizontalPodAutoscaler only scales replica count in response to CPU metrics; it has no awareness of node health, Pod placement, or failure domains. If all current replicas reside on a single node and that node fails, the HPA will eventually trigger replacements, but there will be downtime while new Pods are scheduled, and the replacement Pods could again land on the same surviving node because no spread mechanism exists. It also does nothing to prevent violation of a PDB during a drain, so it cannot provide a high-availability guarantee.

Go deeper

Related to this question