Google ACE Deploying and Implementing a Cloud Solution 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.

• ✗

  Create a custom image with pre-installed patches and code, and use that image in the template

  Why it's wrong here

  Creating a custom image that bakes the patches and code into the boot disk is possible, but it creates a tight coupling between your application version and the machine image. Every time the startup script or code changes, you must rebuild the image, update the instance template, and perform a rolling replacement of the MIG, which is slow and operationally heavy. The startup-script metadata approach keeps the image immutable and lets you update scripts declaratively without image rebuilds, making it better suited for frequent deployments.

• ✗

  After the MIG is created, use gcloud compute ssh to run the script on each instance

  Why it's wrong here

  Running the script via gcloud compute ssh is a purely manual, one-off operation that does not scale to multiple instances and offers no automation for instances added later by autoscaling or MIG repairs. It also depends on SSH keys, network routes, and the instances having a public IP or a bastion, and any instance recreated from the template will not have the patch run. This approach is only useful for debugging, not for managing configuration at scale.

• ✗

  Store the script in Cloud Storage and use gcloud compute instances add-metadata on each instance

  Why it's wrong here

  Storing the script in Cloud Storage and then attaching it with gcloud compute instances add-metadata on each instance is cumbersome because the metadata is set per instance and not inherited from the instance template. New instances created by the MIG during autoscaling or health-check-based recreation will miss the metadata, so you would have to run the command every time an instance is added. Furthermore, this method requires you to know each instance's name and manage the metadata lifecycle manually; the instance template's startup-script metadata is the correct, automated place to define it.

• ✓

  Add the script to the instance template using the metadata key 'startup-script'

  Why this is correct

  Adding the script to the instance template using the metadata key 'startup-script' is the recommended, automated approach because Compute Engine stores the metadata in the instance template and executes the script on every VM boot. The MIG automatically applies this metadata to all instances it creates, including during autoscaling, rolling updates, and instance recreation after a failure. This guarantees the configuration is consistently applied without manual intervention, and the script can be updated by editing the template and rolling out a new version of the MIG.

Go deeper

Related to this question