Associate Cloud Engineer free question 3 / 10 · Domain 2: Planning and implementing a cloud solution
In a project where OS Login is not enabled, you want a contractor to connect by SSH to one VM. The contractor must not be able to reach other VMs in the project. According to the page on adding SSH keys to VMs, how should you register the contractor's public key?
- Block project-wide keys on the target VM and add the key to the project metadata
- Write the public key directly into ~/.ssh/authorized_keys on the target VM
- Add the public key to the metadata of the zone that contains the target VM
- Add the public key to the instance metadata of the target VM
Show the answer and explanation
Answer: D
Why this is correct
A VM that does not use OS Login keeps its SSH keys in Compute Engine project metadata and instance metadata. The page explains that keys in project metadata give access to every VM in the project, while keys in instance metadata give access to that individual VM only. To let someone reach just one VM, you add the public key to the instance metadata of that VM.
Why the other options are wrong
"Block project-wide keys on the target VM and add the key to the project metadata" … A key in project metadata works on every VM in the project except the VMs that block project-wide keys. Blocking the keys on the target VM stops that VM from accepting the key, while the other VMs you want to protect would still accept it. This does the opposite of what you intend.
"Write the public key directly into ~/.ssh/authorized_keys on the target VM" … The page warns that a public key written directly into ~/.ssh/authorized_keys can be overwritten by the guest agent on the VM. It recommends adding keys with a supported method: the console, the gcloud CLI, or the REST API.
"Add the public key to the metadata of the zone that contains the target VM" … The page states that you cannot set SSH keys in zone metadata. SSH keys can be placed only in project metadata and instance metadata.
Key point
Managing keys through metadata carries a risk. Anyone or any service account that can change project metadata can add keys to every VM, which can give access to people you did not intend. An expired key is not removed from metadata automatically, although it can no longer be used for new connections. On a VM where OS Login is enabled, the guest agent ignores the keys in metadata.
Go to the Associate Cloud Engineer practice app (10 free questions; purchase unlocks all questions)