Connecting to a Compute Engine VM sounds like a basic task, but the Professional Cloud Architect exam treats it as an access-control problem. The questions usually hide behind a scenario about a locked-down environment, a Windows workload, or a user who shouldn't be managing SSH keys themselves. If you understand how SSH, RDP, OS Login, and IAP tunneling fit together, those questions become straightforward.
SSH stands for Secure Shell. It's the protocol you use to log into a Linux Compute Engine VM and run commands as if you were sitting at the machine. The connection is encrypted end to end, so commands and any data you transfer are protected from interception. SSH also handles secure file transfer and port forwarding, which is why it shows up everywhere in cloud workflows.
When you connect to a VM through the Google Cloud console or the gcloud command line, Google generates and applies SSH keys for you automatically. That's the default path and it's fine for most cases. Behind the scenes, the public key gets pushed to the instance and the private key stays on your client.
You also have a few security knobs to turn. You can require two-step verification for SSH, block project-wide SSH keys so a key added at the project level can't reach a specific VM, or add SSH keys manually if you want to manage them yourself. The catch on that last option is that manually added keys stop working the moment OS Login is enabled on the VM. That's a common gotcha.
One more thing to check before you blame anything else: the firewall. If SSH isn't connecting, the cause is often a firewall rule that doesn't allow TCP port 22 from your source. The default network allows it, but custom networks or hardened environments frequently don't. I've watched plenty of debugging sessions end with someone realizing they blocked SSH themselves and forgot.
OS Login is the feature that ties VM access to IAM. When you turn it on, users authenticate with their Google Cloud user accounts, and whether they get into the VM depends on the IAM roles they hold. Google Cloud also takes over public SSH key management, so you don't have to push or rotate keys per machine.
The flow is simple. A user runs gcloud compute ssh against a VM. IAM checks whether that user has one of the OS Login roles. If yes, the connection goes through. If no, it's denied at the access layer before any SSH handshake matters.
There are three roles to know:
The architectural argument for OS Login is centralization. Instead of every VM having its own list of authorized SSH keys to audit and rotate, you grant and revoke access by changing IAM roles. That's the answer the Professional Cloud Architect exam wants when a question asks how to manage SSH access at scale or how to remove access for a departing employee across hundreds of VMs.
Hardened environments often prohibit public IPs on VMs. That removes a whole class of external attack surface, but it also means you can't SSH in directly from the internet. The answer is Identity-Aware Proxy.
IAP acts as a managed proxy that routes your SSH connection through Google's internal network. The VM doesn't need a public IP. Your client connects to IAP, IAP authenticates you against IAM, and the SSH session is tunneled through.
The permission you need is iap.tunnelInstances.accessViaIAP on the user or service account making the connection. Without it, IAP refuses the tunnel.
The command is:
gcloud compute ssh INSTANCE_NAME --zone ZONE --tunnel-through-iapThe --tunnel-through-iap flag is what tells gcloud to route the connection through the IAP tunnel instead of trying a direct connection to a public IP. On the exam, anytime you see a scenario where VMs can't have public IPs but engineers still need shell access, IAP tunneling is the answer.
SSH is for Linux. Windows VMs use Remote Desktop Protocol. RDP is a Microsoft protocol that gives you a full graphical session against the remote machine, with mouse, keyboard, and desktop, as if you were physically at the console.
To connect to a Windows VM on Compute Engine, you need credentials for a Windows user account on that VM. Two ways to get them:
gcloud compute reset-windows-password to generate a fresh secure password from the command line.Once you have the credentials, any RDP client will connect to the VM's IP on port 3389. From there you manage the machine the same way you would any Windows server.
The exam framing here is usually a question about which tool to use. If the workload is Windows, the answer is RDP and gcloud compute reset-windows-password. If the workload is Linux, the answer is SSH, and depending on the constraints, OS Login or IAP tunneling on top.
The Professional Cloud Architect exam doesn't ask you to memorize gcloud flags. It asks you to recognize which access pattern fits a given constraint. Three patterns are worth keeping straight:
OS Login is the answer to most questions about centralizing SSH key management or revoking access at scale. IAP tunneling is the answer to most questions about restricted-network environments. Knowing the right tool for the constraint is what these questions are actually testing.
My Professional Cloud Architect course covers SSH, RDP, OS Login, and IAP tunneling alongside the rest of the compute material.
