professional-cloud-data-engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A data engineering team manages a real-time analytics web application deployed on a Managed Instance Group (MIG) behind an external Application Load Balancer. During periods of heavy data ingestion, some virtual machines become temporarily busy and are slow to respond to requests.
The current configuration uses a single, aggressive health check for both the load balancer and the MIG's autohealing policy. As a result, the autohealer mistakes these busy instances for failed instances and prematurely recreates them, which reduces overall system availability and causes cascading failures.
What should you do to ensure the system gracefully handles temporary load spikes while still automatically recovering from true application failures?
Configure a Cloud Monitoring alert to trigger a Cloud Function that live migrates the busy virtual machines to a different zone
Modify the existing health check to use a TCP probe instead of an HTTP probe to bypass the application layer and prevent busy instances from being recreated
Disable the autohealing policy on the Managed Instance Group and configure the load balancer health check to automatically recreate unresponsive instances
Create a separate, more conservative application-based health check specifically for the autohealing policy, while keeping the aggressive health check for the load balancer
Configure a Cloud Monitoring alert to trigger a Cloud Function that live migrates the busy virtual machines to a different zone
Modify the existing health check to use a TCP probe instead of an HTTP probe to bypass the application layer and prevent busy instances from being recreated
Disable the autohealing policy on the Managed Instance Group and configure the load balancer health check to automatically recreate unresponsive instances
Create a separate, more conservative application-based health check specifically for the autohealing policy, while keeping the aggressive health check for the load balancer
In Google Cloud, Managed Instance Groups (MIGs) utilize health checks for two distinct purposes: load balancing and autohealing. While a load balancer uses health checks to determine where to route user traffic, an autohealing policy uses health checks to determine if a virtual machine (VM) is fundamentally broken and needs to be completely deleted and recreated.
Using a single, aggressive health check for both purposes is a common anti-pattern. An aggressive autohealer mistakes busy instances for failed instances and unnecessarily restarts them. Separating the health checks allows you to tune the load balancer for optimal user experience (fast failover) and tune the autohealer for optimal infrastructure stability (conservative recreation).
StudyCerts
StudyCerts