Practice Test 3 | Google Cloud Certified Professional Cloud Architect | Dumps | Mock Test
Your development team has installed a new Linux kernel module on the batch servers in Google Compute Engine (GCE) virtual machines (VMs) to speed up the nightly batch process. Two days after the installation, 50% of the batch servers failed the nightly batch run. You want to collect details on the failure to pass back to the development team. Which three actions should you take? (Select THREE)
A. Identify whether a live migration event of the failed server occurred, using the activity log.
B. Use Operations Suite (formerly Stackdriver) Logging to search for the module log entries.
C. Use gcloud or Cloud Console to connect to the serial console and observe the logs.
D. Read the debug GCE Activity log using the API or Cloud Console.
E. Export a debug VM into an image and run the image on a local server where kernel log messages will be displayed on the native screen.
F. Adjust the Google Operations Suite (formerly Stackdriver) timeline to match the failure time and observe the batch server metrics.
Correct Answer B, C, and F
A – Identify whether a live migration event of the failed server occurred, using the activity log.
This answer is ambiguous nor is it the best answer compared to others.
B – Use Operations Suite (formerly Stackdriver) Logging to search for the module log entries. Logs can be analyzed to figure out what all process was run on the servers and which all services/users accessed the same.
C – Use gcloud or Cloud Console to connect to the serial console and observe the logs.
Interacting with the Serial Console (https://cloud.google.com/compute/docs/instances/interacting-with-serial-console): The instance’s operating system, BIOS, and other system-level entities often write output to the serial ports and can accept input such as commands or answers to prompts.
Since you have batch servers with the same failure time and behavior, you may take one of the instances to investigate
D – Read the debug GCE Activity log using the API or Cloud Console. This is a system (servers) failure, not an application failure.
E – Export a debug VM into an image and run the image on a local server where kernel log messages will be displayed on the native screen. This is not going to work.
F – Adjust the Google Operations Suite (formerly Stackdriver) timeline to match the failure time and observe the batch server metrics.
Since you have 50% servers with known same failure time and behavior, aligning the failure time with your instances, most likely you can find clue for the failure causes such as CPU, disk, or network.
Comments are closed, but trackbacks and pingbacks are open.