11.1 Connecting to and Managing Running Compute Engine Instances

Why This Topic Matters

Domain 4 of the Associate Cloud Engineer (ACE) exam guide, "Ensuring successful operation of a cloud solution," opens with two bullets that sound simple but hide a lot of exam traps: remotely connecting to the instance and viewing current running VM inventory. In practice this means ACE will hand you a scenario — "a VM has no external IP," "a security team wants centrally revocable SSH access," "a script needs to enumerate every running VM in a project" — and ask you to pick the right gcloud command or connection mechanism. Getting the mechanics of Identity-Aware Proxy (IAP), OS Login, and instance metadata right is a recurring theme across several exam domains, not just this one, because the same SSH-key and IAM concepts resurface in the security domain (Chapter 15).

Ways to Connect to a Running Instance

Google Cloud supports four practical connection paths to a Linux Compute Engine VM:

1. SSH-in-browser — a button in the Cloud Console that opens a terminal directly in the browser. It generates ephemeral SSH keys automatically, so there is nothing to manage, but it requires the instance to have connectivity the console can reach (an external IP, or IAP if none).
2. gcloud compute ssh — the command-line equivalent: gcloud compute ssh INSTANCE_NAME --zone=ZONE --project=PROJECT_ID. The first time you run this against a project, gcloud generates a persistent SSH key pair and pushes the public key to instance or project metadata for you.
3. Native OpenSSH / PuTTY / Secure Shell extension — you add your own public key to instance or project metadata, then connect directly with ssh -i PATH_TO_KEY USERNAME@EXTERNAL_IP. This is the path enterprises use when they want to bring their own key management.
4. IAP TCP forwarding — the only supported method when a VM has no external IP address and you do not want to stand up a bastion host or VPN. IAP proxies the TCP connection through Google's infrastructure.

OS Login vs. Metadata-Based SSH Keys

This is one of the most heavily tested distinctions in this section:

A classic exam trap: a team sets an SSH key in project metadata, expecting it to reach only one VM. In fact, project-level metadata SSH keys propagate to every instance in the project unless that specific instance has the --metadata block-project-ssh-keys=TRUE flag (or the equivalent console checkbox "Block project-wide SSH keys") set.

IAP TCP Forwarding: The No-External-IP Path

When a VM has only an internal IP (the recommended posture for production workloads), IAP TCP forwarding is the standard ACE-tested answer for how an engineer still reaches it for troubleshooting. Two things must be true:

1. A firewall rule must allow ingress from IAP's fixed source range:

gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
  --direction=INGRESS --action=allow --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

35.235.240.0/20 is a Google-owned, fixed CIDR block used exclusively for IAP TCP forwarding traffic — memorize this range, it appears verbatim in exam scenarios. Add tcp:3389 to the same rule for Windows RDP. 2. The connecting principal needs both roles/iap.tunnelResourceAccessor (to use the tunnel) and a compute role such as roles/compute.instanceAdmin.v1 or roles/compute.osLogin (to reach the instance itself).

The actual tunnel is opened with:

gcloud compute start-iap-tunnel INSTANCE_NAME 3389 \
  --local-host-port=localhost:LOCAL_PORT --zone=ZONE

or, more commonly for SSH, simply gcloud compute ssh INSTANCE_NAME --tunnel-through-iap.

Managing Running Instances: The Lifecycle Command Set

Beyond connecting, ACE tests the everyday operational commands for a fleet of VMs:

instances reset is a common distractor on the exam: candidates confuse it with stop. Reset performs a hard reboot without a graceful OS shutdown — correct for a hung VM, wrong for routine maintenance where stop (or suspend, which preserves in-memory state to persistent disk for a faster resume) is the safer choice.

Realistic Exam Scenario

A finance team's VMs sit in a private subnet with no external IPs for compliance reasons, but the platform team occasionally needs to SSH in for troubleshooting, and security requires that every login be traceable to a named engineer. The ACE-correct architecture is: enable OS Login on the project (gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE), grant engineers roles/compute.osLogin plus roles/iap.tunnelResourceAccessor, and create a firewall rule allowing tcp:22 from 35.235.240.0/20 only. No bastion host, no VPN, no external IPs — and every session is tied to an IAM identity.