Exam Professional Cloud Architect topic 1 question 34 discussion

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.

ABE is much make sense to me

I will go for ACE.

B vs C is the question. I vote for B , since activity logs now have been moved to audit logs and they provode system event information. C is moee real time, it will be a task to extract all the logs and put it to a file and share with dev team. Anyways audit logs is already abstracting that work for you. Hence ABE is the right answer as per me

I chose B over C as both options trying to read/observe logs. But C looks like reading at the runtime. Give that, it's a nightly batch process, B seems to suitable post error occurrence.

A. Use Stackdriver Logging to search for the module log entries: This will help you identify any errors or issues related to the new kernel module that were logged during the batch process. C. Use gcloud or Cloud Console to connect to the serial console and observe the logs: The serial console logs can provide detailed information about the boot process and any kernel-related messages that might indicate why the batch servers failed. D. Identify whether a live migration event of the failed server occurred, using the activity log: Live migration events can sometimes cause disruptions. Checking the activity log will help you determine if this was a factor in the failures.

A. Use Stackdriver Logging to search for the module log entries: This will help you identify any errors or issues related to the new kernel module that were logged during the batch process. C. Use gcloud or Cloud Console to connect to the serial console and observe the logs: The serial console logs can provide detailed information about the boot process and any kernel-related messages that might indicate why the batch servers failed. D. Identify whether a live migration event of the failed server occurred, using the activity log: Live migration events can sometimes cause disruptions. Checking the activity log will help you determine if this was a factor in the failures.

A. Use Stackdriver Logging to search for the module log entries: This is crucial. Stackdriver Logging aggregates logs from various sources, including your VMs. You can search for specific entries related to the new kernel module to identify errors, warnings, or unusual behavior that might explain the failures. C. Use gcloud or Cloud Console to connect to the serial console and observe the logs: The serial console provides access to the VM's output even if the system is unresponsive. This can be invaluable for capturing kernel panic messages, boot errors, or other critical information that might not be available through standard logging channels. E. Adjust the Google Stackdriver timeline to match the failure time, and observe the batch server metrics: Stackdriver Monitoring provides detailed performance metrics for your VMs. By aligning the timeline with the failures, you can analyze CPU usage, memory consumption, disk I/O, and network activity.

considering that logs from the serial console might not be useful after two days: A. Use Stackdriver Logging to search for the module log entries: This will help you identify any errors or issues logged by the new kernel module. B. Read the debug GCE Activity log using the API or Cloud Console: This can provide information on significant events like reboots or live migrations that might have affected the batch process. E. Adjust the Google Stackdriver timeline to match the failure time, and observe the batch server metrics: This helps correlate the failure with any anomalies in the server metrics, providing insights into what might have gone wrong.

Answer is ACE

Vote ACE

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