ACE A. Use Stackdriver Logging to search for the module log entries = Check logs C. Use gcloud or Cloud Console to connect to the serial console and observe the logs = Check grub messages, remember new kernel module was installed. E. Adjust the Google Stackdriver timeline to match the failure time, and observe the batch server metrics = Zoom into the time window when problem happened.

Go for A,B,E. C is when the VM is running , but in this case the sentence says “recollect”. It means that “error ever” already happened.

I'm not sure but I vote for ABE

ACE makes sense. A and E dont have any doubts. Questions is that if it is B, C or F. Whats' use of serial console if team does not use it for logging especially kernal related updates. that makes sense to choose C.

Most automated way, with C, collecting from VMs involves a lot of manual efforts

ABE is correct

I'm really not sure here. A and E are just OK, and for me the final point is between B o C. many ppl is saying C, but, the question says that the VM's already failed and you're investigating what happened in the past. Anyway, there are 2 ways to interpret this, from my point of view: 1) The failure happened and it's going to happen again. In this case ACE would be maybe the best option BUt 2) The failure happened and you want to investigate this failure, which happened in the past. Therefore ABE would be the right one, as you are "splunking" in the logs of the past, not having a review of the logs as they happen. from my personal interpretation I'd go with ABE

ACE To collect details on the failure of the batch servers in GCE VMs, you can take the following actions: A: Stackdriver Logging can help you identify any issues related to the new Linux kernel module by searching for log entries related to the module. C: Connecting to the serial console allows you to view the logs in real-time as the batch servers are running. This can help you identify any issues related to the new kernel module. E: By adjusting the timeline in Stackdriver to match the failure time, you can view the batch server metrics during the time when the failures occurred. This can help you identify any issues related to the new kernel module. Other options, such as reading the debug GCE Activity log using the API or Cloud Console, identifying whether a live migration event of the failed server occurred, or exporting a debug VM into an image and running the image on a local server, may not provide the necessary information to understand

ACE by eliminating the incorrect answers

ADE seems correct

I vote for.

This question is very poorly asked. There is no place saying if the live migration is enabled. If a VM is not set to live migrate, the VM is terminated during host system events. There is no place saying if you run into problems accessing your instance through SSH or need to troubleshoot an instance that is not fully booted, so you can enable interactive access to the serial console. C: https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-using-serial-console D: https://cloud.google.com/compute/docs/instances/live-migration

ACE are the correct choices

vote ACE

I would say that Q26 = ABE A - since it investigates logs of Linux kernel module installed recently. For that Log Agent should be installed on VMs and Linux syslog is streamed by default to Stackdriver Logging via agent. So, this answer is relevant to Q's context, it checks if new Linux kernel runs OK. B - investigates "app-level" issues on GCE, logs API called from this VM, system events, etc. C - review of Serial Log is useful only for HW/OS crashes, and only during short period of time (since only last 1MB of logs are stored there, if more logs needed then they are streamed to Stackdriver logging). So, this option doesn't fit 2 days period and also serves different failure types. D - live migration event is irrelevant to this Q (transferring hot/running context of one VM to another transparently, so original VM can be maintained – BIOS/HW updates). Even if that happens, then GCE activity logs in B should cover this. E - monitoring of metrics at the time of failure makes sense for troubleshooting. F - smth long and ridiculous.

If I'm reading "F" correctly, it is to export a VM and move it back to a "local" server which I'm reading as "on-prem", your laptop, or your local datacenter.(aka NOT GCP) So if I'm reading that correctly, that is a very ineffective idea. Keep it in GCP and use the powerful GCP tools. If somebody feels that I'm reading that wrong, I would love to see from a different POV. If you are reading that the same as me, then rule out F.

We can also rule out D, Live Migration Event. Unless it is called out, regular VMs can be live migrated without an notice of the guest os. So this should not be your focus. Rule out D. https://cloudplatform.googleblog.com/2015/03/Google-Compute-Engine-uses-Live-Migration-technology-to-service-infrastructure-without-application-downtime.html