OS Login is a Compute Engine feature that changes how SSH access to your VMs is managed. Instead of distributing and rotating SSH keys manually, you grant IAM roles to users, and Google handles the keys for you behind the scenes. This article covers what OS Login does, the three roles it introduces, and how the Associate Cloud Engineer exam tests it.
It does not cover OS Login with two-factor authentication, the Linux user account mapping in detail, or how OS Login interacts with third-party identity providers. The goal here is to give you the ACE exam version, which focuses on the IAM-based access model and the role names.
Without OS Login, SSH access to a Compute Engine VM is controlled by SSH keys. Project-wide SSH keys grant access to every VM in the project. Per-instance SSH keys grant access to a specific VM. When someone joins or leaves the team, you have to add or remove their key in the right place. When you have a lot of VMs and a lot of users, this gets messy fast. Keys can be missed, old keys can stick around, and there is no central audit trail.
OS Login replaces all of that with IAM. You enable OS Login on the VM, grant a user the right IAM role, and they can SSH in. Take the role away, and they cannot. The keys themselves are managed automatically, so no one is copying public keys around manually.
When OS Login is enabled, users authenticate using their Google Cloud user accounts. Their public SSH keys are generated and applied automatically by GCP. When a user attempts to SSH into a VM, IAM checks whether they have the appropriate role. If yes, they get in. If no, they do not.
Crucially, when OS Login is enabled, manually-added SSH keys do not work. This is intentional. The whole point is to centralize control through IAM. If someone can bypass IAM by pasting a public key into the metadata, the system does not actually centralize anything. So enabling OS Login disables that path.
OS Login introduces three IAM roles that the Associate Cloud Engineer exam expects you to know:
Compute OS Login. Grants SSH access to a VM without administrative privileges. The user can log in and run normal commands but cannot run sudo or otherwise act as root. This is the role you give to typical developers who need to deploy or debug applications.
Compute OS Admin Login. Grants SSH access with administrative privileges. The user can log in as root, install packages, change system configuration, do anything. This is for people who actually need full control of the VM, like sysadmins or platform engineers.
Compute OS Login External User. Grants the same access as Compute OS Login, but specifically for users outside your organization's domain. If you need to give an external contractor SSH access to a VM, this is the role you grant. Without it, IAM will refuse to authenticate the external identity.
OS Login is enabled through metadata. You can set it on a single VM or set it project-wide so every new VM in the project gets it by default. The metadata key is enable-oslogin, and the value is TRUE.
gcloud compute instances add-metadata INSTANCE_NAME \
--metadata enable-oslogin=TRUE \
--zone=us-central1-aFor project-wide enablement:
gcloud compute project-info add-metadata \
--metadata enable-oslogin=TRUEOnce enabled, you grant the Compute OS Login role to whoever needs access:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=user:alice@example.com \
--role=roles/compute.osLoginA few patterns show up consistently.
The first is a question about how to centralize SSH key management or remove the burden of distributing keys manually. The answer is OS Login. If the scenario mentions large numbers of VMs, frequent personnel changes, or the desire to use existing IAM roles for VM access, OS Login is the feature being tested.
The second pattern is role identification. A question describes a user who needs SSH access to a VM and asks which role to grant. If the user is internal and does not need root, the answer is Compute OS Login. If they need root, it is Compute OS Admin Login. If they are external, it is Compute OS Login External User.
The third pattern is a question about why someone's manually-added SSH key stopped working. The answer is usually that OS Login was enabled, which disables manual key paths. This is a subtle one but it shows up.
If you see "centralize SSH key management" or "manage VM access through IAM" in a question, think OS Login. If you see a role name starting with "Compute OS Login," that scenario is about OS Login.
OS Login replaces manual SSH key management with IAM-based access. You enable it on a VM or across a project, you grant users one of the three OS Login roles, and SSH keys are handled automatically. Compute OS Login for normal users, Compute OS Admin Login for users who need root, Compute OS Login External User for users outside your organization.
The Associate Cloud Engineer exam tests this in two ways: as the answer to "how do we centralize SSH access management" and as a multiple-choice question about which specific role to grant. If you remember the three role names and what each one does, you have the topic covered.
My Associate Cloud Engineer course covers OS Login alongside the other Compute Engine security features the exam tests, including project-wide SSH key blocking and how OS Login interacts with the broader IAM model.
