Exam Associate Cloud Engineer topic 1 question 121 discussion

Really tricky question. Ideal scenario would be 1. create new template, while creating ensure that in the new template disks.autoDelete=true, 3. delete existing persistent disks, 4. make rolling update ... In order to switch to new template we need "Rolling update". Unfortunately, it is not mentioned. With current options C - not correct, we cannot update existing template D - not correct, we cannot delete existing template when it is in use (just checked in GCP) (We need rolling update) B - will not solve our problem without Rolling update A - This is the only option (I know that it can be temporary) that will work without Rolling update according to https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-migs

Correct Answer is (C): Your instance template has set the disks.autoDelete option to false for boot persistent disks so that when a VM has been deleted (for example, because of autohealing), the persistent disk was not deleted. When the managed instance group attempted to recreate the VM with the same name, it ran into the same issue where a persistent disk already exists with the same name. Delete the existing persistent disk to resolve the immediate problem and update the instance template to set the disks.autoDelete to true if you would like boot persistent disks to be deleted alongside the instance https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances#troubleshooting

Opción Acción Comentario A Crear un nuevo instance template con sintaxis válida y eliminar discos persistentes con el mismo nombre que las instancias. Correcto, pero incompleto: no aborda el problema recurrente, solo lo evita momentáneamente. C Verificar que el template actual tiene sintaxis válida, eliminar discos persistentes conflictivos, y configurar disks.autoDelete = true. ✅ Solución completa: evita el problema ahora y previene que ocurra de nuevo.

If you don’t set autoDelete: true, disks from deleted VMs will stick around Google recommends setting autoDelete: true in MIG templates to avoid this exact scenario

From my understanding this VM creation issue is based on boot disk from a previous failed VM exists within the MIG making the MIG unable to create a New VM for that failed VM (Auto healing). all the answers are based on this solution. (There might be other issues as per below document which needs other solutions). But the document states below for boot disk issue scenario in a MIG, https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-migs "The boot disk already exists By default, a new boot persistent disk is created when you create an instance. The name of the boot disk matches the name of the VM. If you name a VM my-instance, the disk is also named my-instance. If a persistent disk already exists with that name, the request fails. To resolve this issue, you can optionally take a snapshot, and then delete the existing persistent disk."

Ensure the template is valid. Persistent disk naming: Avoid naming disks the same as instances. Automatic deletion: Set disks.autoDelete to true in the template for automatic disk removal.

Is not C "Instance templates are designed to create instances with identical configurations. So you cannot update an existing instance template or change an instance template after you create it." https://cloud.google.com/compute/docs/instance-templates#how_to_update_instance_templates

I have no idea and looking at options and explanations from everyone here A, C or D could be the answers. I thought it was D personally, but all answers seem to not make any sense. Usually you can discard one or 2, but here all are the same to me.

All questions are from here.

correct answer is C. It is not updating an instance template, just validate the syntax. The same instance template was working before, so why would you need to edit it? the issue should be in the disk name.

Correct answer is A : Create an instance template that contains valid syntax which will be used by the instance group. Delete any persistent disks with the same name as instance names.

why we dont prefer option B? it says be sure names are different. but option A deletes discs. if we can change names why to delete them?

Answer is A As many have mentioned here C and D is straight NO, C talks about updating the instance template and D talks about deleting an instance template BUT as per google documentation you cannot delete an instance template nor update it if it is in use. So A is the only one the makes sense here. https://cloud.google.com/compute/docs/instance-templates#how_to_update_instance_templates

Vote C https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-migs https://cloud.google.com/sdk/gcloud/reference/compute/instances/set-disk-auto-delete

C is the correct answer. 1. Ensure you don’t have any persistent disks with the same name as the VM instance. 2. Ensure the disk autodelete property is turned on (disks.autoDelete set to true). 3. Ensure instance template syntax is valid

Answer : A As many have mentioned here C and D is straight NO, C talks about updating the instance template and D talks about deleting an instance template BUT as per google documentation you cannot delete an instance template nor update it if it is in use. So A is the only one the makes sense here. https://cloud.google.com/compute/docs/instance-templates#how_to_update_instance_templates

Correct answer is A You don't have the option to edit an existing instance.