Pass Associate-Cloud-Engineer Exam Guide

In order to enable auto-healing, you need to group the instances into a managed instance group. Managed instance groups (MIGs) maintain the high availability of your applications by proactively keeping your virtual machine (VM) instances available. An auto-healing policy on the MIG relies on an application-based health check to verify that an application is responding as expected. If the auto-healer determines that an application isnt responding, the managed instance group automatically recreates that instance.

It is important to use separate health checks for load balancing and for auto-healing. Health checks for load balancing can and should be more aggressive because these health checks determine whether an instance receives user traffic. You want to catch non-responsive instances quickly, so you can redirect traffic if necessary. In contrast, health checking for auto-healing causes Compute Engine to proactively replace failing instances, so this health check should be more conservative than a load balancing health check.

In Google compute engine, if predefined machine types don’t meet your needs, you can create an instance with custom virtualized hardware settings. Specifically, you can create an instance with a custom number of vCPUs and custom memory, effectively using a custom machine type. Custom machine types are ideal for the following scenarios:

   1. Workloads that aren’t a good fit for the predefined machine types that are available to you.

   2. Workloads that require more processing power or more memory but don’t need all of the upgrades that are provided by the next machine type level.

In our scenario, we only need a memory upgrade. Moving to a bigger instance would also bump up the CPU which we don’t need so we have to use a custom machine type. It is not possible to change memory while the instance is running so you need to first stop the instance, change the memory and then start it again. See below a screenshot that shows how CPU/Memory can be customized for an instance that has been stopped.

The requirement is for private communication between a Cloud Run service and a GKE API, following best practices.

Option A exposes the GKE API to the public internet, which violates the "privately reach" requirement. Relying on dynamic IP allowlisting with Cloud Armor is complex and less secure than private networking.

Options B and C configure overly permissive firewall rules (allowing all egress or ingress) and do not establish the necessary private network path between Cloud Run (which normally runs outside your VPC) and the GKE cluster within your VPC.

Option D describes the standard Google-recommended pattern for this scenario:

Internal Application Load Balancer (ILB): Expose the GKE service (API) using an ILB. This gives the service a private IP address accessible only within the VPC network (or connected networks).

Cloud DNS: Create a private DNS zone and record pointing a fully qualified domain name (FQDN) to the ILB's private IP address. This allows services to reach the API via a stable name instead of an IP.

Serverless VPC Access Connector: This connector creates a bridge allowing serverless services like Cloud Run to send traffic into your VPC network.

Cloud Run Configuration: Configure the Cloud Run service to use the VPC Access connector. The application code can then call the GKE API using its private FQDN registered in Cloud DNS.

This setup ensures traffic flows entirely over private networks (within the VPC via the ILB and through the VPC Access connector), meeting the private communication requirement securely and reliably.

"...we recommend that you enable Cloud Billing data export to BigQuery at the same time that you create a Cloud Billing account.