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.

GCE Activity log does not provide debug logs as they lack kernel application-level details, while The serial console provides low level access to VMs boot and kernel logs. Therefore, C wins in this case.

A & E - Use Cloud Logging (Previously Stackdriver logging) search and filter module log entries. Provides syslog, kernel logs, app logs etc and can be filterer by VM name, time range, severity.. C - Serial console output - Kernel panics, boot failures or critical errors related to a kernel module often print messages directly to serial console before OS might even fully functional. [Option B could be helpful but for the scenario in question I won't go to GCE activities logs(Cloud Audit Logs) skipping C (Serial Console Output). It gives the information what's happening to VM from control pane's perspective, it won't directly tell me kernel module's internal errors... ]

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