A few days after JencoMart migrates the user credentials database to Google Cloud Platform and shuts down the old server, the new database server stops responding to SSH connections. It is still serving database requests to the application servers correctly. What three steps should you take to diagnose the problem? (Choose three.)

The database server is still serving requests, indicating the core database and application are functional, but SSH is not. This points to a network or OS-level issue. Taking a snapshot of the disk and connecting it to a new machine allows for safe, non-disruptive investigation of the disk's contents and configuration without affecting the running database instance. Checking inbound firewall rules is crucial because SSH connectivity relies on specific ports (typically 22) being open. A recent change or misconfiguration could be blocking access. Printing the Serial Console output provides low-level boot and system messages, which can reveal OS-level errors, network configuration issues, or problems with the SSH daemon itself. Activating the interactive console allows direct command-line access for deeper diagnostics if the VM is still running but SSH is broken. Deleting the VM and disks is destructive and should only be a last resort after diagnosis. Deleting the instance and attaching the disk to a new VM is similar to taking a snapshot but is less safe as it directly modifies the original disk. Connecting to another network is less likely to be the primary issue if the application is still working, and it doesn't directly diagnose the root cause on the original network.