After migrating the credentials database to Google Cloud and shutting down the old server, the new DB VM stops responding to SSH but continues serving database requests. Which three diagnostic steps should you take?

The VM is serving database requests, indicating the core system is operational, but SSH access is lost. 1. Take a snapshot of the disk and attach it to a new machine to investigate: This is a safe and non-disruptive way to investigate the disk's contents without affecting the running database server. You can then mount the snapshot on another VM to analyze logs or configuration files. 2. Check inbound firewall rules for the network the VM is on: SSH connectivity relies on specific firewall rules (typically port 22). A misconfigured or missing rule could block SSH access while allowing database traffic. 3. Print the instance Serial Console output, enable the interactive console, and investigate: The serial console provides direct, out-of-band access to the VM's boot process and system messages, even if networking or SSH is down. This can reveal critical errors or allow for basic troubleshooting commands. Deleting the VM and disks, or deleting the instance and reattaching the disk, would cause downtime for the database, which is undesirable if the database is still serving requests. Connecting the VM to another network with simplified firewall rules is not a standard diagnostic step and could introduce new network complexities or security risks.