SSH access and metadata in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding SSH Key Metadata in GCP

In Google Cloud Platform, when you add an SSH public key to a VM instance's metadata, what does this metadata entry control?

A It allows the specified user to SSH into the VM using the corresponding private key.

B It disables password authentication for all users on the VM.

C It restricts SSH access only to users with the Google Cloud Console account.

D It automatically installs the SSH server software on the VM instance.

💡 Hint

Think about what SSH keys do in general for secure access.

Adding an SSH public key to the VM's metadata authorizes the corresponding private key holder to connect via SSH. It does not install software or restrict access to console users only.

❓ Configuration

intermediate

Configuring SSH Access via Project-wide Metadata

You want to allow a new user to SSH into all VM instances in your GCP project without adding keys to each VM individually. Where should you add the user's SSH public key?

A Add the SSH public key to each VM instance's local metadata individually.

B Add the SSH public key to the project-wide metadata under the 'ssh-keys' entry.

C Add the SSH public key to the firewall rules to allow SSH traffic.

D Add the SSH public key to the service account attached to the VM instances.

💡 Hint

Think about how project-wide metadata affects all instances.

Project-wide metadata applies to all VM instances in the project, so adding SSH keys there grants access to all VMs without per-instance configuration.

❓ security

advanced

Preventing Unauthorized SSH Access via Metadata

Which of the following practices best prevents unauthorized SSH access to your GCP VM instances when using SSH keys in metadata?

A Allow SSH access only from any IP address to avoid connection issues.

B Disable the SSH service on all VM instances and use only serial console access.

C Add all users' SSH keys to the default service account metadata.

D Regularly rotate SSH keys and remove unused keys from instance and project metadata.

💡 Hint

Think about key management and minimizing access.

Rotating keys and removing unused keys reduces risk of compromised keys being used. Disabling SSH or allowing all IPs is not practical or secure.

❓ service_behavior

advanced

Effect of Removing SSH Keys from Metadata

If you remove a user's SSH public key from the project-wide metadata, what happens when that user tries to SSH into a VM instance that does not have their key in its local metadata?

A The user will be prompted to enter a password instead of using the key.

B The user will still be able to SSH because keys are cached on the VM.

C The user will be denied SSH access because their key is no longer authorized.

D The VM instance will automatically add the user's key back from the Google Cloud Console.

💡 Hint

Consider how SSH key authorization works with metadata.

Removing the key from project-wide metadata revokes access unless the key exists in local metadata. Keys are not cached permanently on VMs.

❓ Architecture

expert

Designing Secure SSH Access with Metadata and OS Login

You want to enforce centralized SSH access control using Google Cloud OS Login instead of managing SSH keys in metadata. Which statement correctly describes the behavior when OS Login is enabled on VM instances?

A SSH keys in instance or project metadata are ignored; access is controlled by IAM roles assigned to users.

B SSH keys in metadata override OS Login settings and grant access regardless of IAM roles.

C OS Login disables SSH access completely and requires use of the Google Cloud Console only.

D OS Login requires manually adding SSH keys to each VM's local metadata for access.

💡 Hint

Think about how OS Login integrates with IAM and metadata.

When OS Login is enabled, SSH key management moves to IAM roles and user accounts, ignoring SSH keys in metadata for access control.

Practice

1. What is the main purpose of SSH access in Google Cloud Platform (GCP)?

easy

A. To securely connect to virtual machine instances

B. To store large files in the cloud

C. To monitor network traffic

D. To create new virtual machines automatically

Solution

1. Step 1: Understand SSH access

   SSH (Secure Shell) is a protocol used to securely connect to remote machines, such as virtual machines in GCP.

2. Step 2: Identify SSH use in GCP

   In GCP, SSH access allows users to securely log into VM instances to manage and operate them.

3. Final Answer:

   To securely connect to virtual machine instances -> Option A

4. Quick Check:

   SSH access = secure VM connection [OK]

Hint: SSH is for secure remote login to VMs [OK]

Common Mistakes:

• Confusing SSH with storage or monitoring services
• Thinking SSH creates VMs instead of connecting to them

2. Which of the following is the correct way to add an SSH key to a VM instance's metadata in GCP?

easy

A. Add the SSH key to the project billing settings

B. Add the SSH key to the instance's firewall rules

C. Add the SSH key to the VM's disk storage

D. Add the SSH key to the instance's metadata under the 'ssh-keys' key

Solution

1. Step 1: Understand where SSH keys are stored

   SSH keys are stored in metadata, which is a place to keep configuration info for VMs.

2. Step 2: Identify correct metadata key

   The correct metadata key for SSH keys is 'ssh-keys' at the instance or project level.

3. Final Answer:

   Add the SSH key to the instance's metadata under the 'ssh-keys' key -> Option D

4. Quick Check:

   SSH keys stored in 'ssh-keys' metadata [OK]

Hint: SSH keys go in 'ssh-keys' metadata key [OK]

Common Mistakes:

• Adding SSH keys to firewall rules instead of metadata
• Trying to store SSH keys in disk storage or billing settings

3. Given the following metadata setup for a VM instance in GCP:

{"ssh-keys": "user:ssh-rsa AAAAB3Nza... [e-mail]"}

What will happen when you try to SSH into this VM as 'user'?

medium

A. SSH connection will succeed using the provided public key

B. SSH connection will be denied due to missing keys

C. SSH will prompt for a password instead of using keys

D. The VM will restart automatically

Solution

1. Step 1: Analyze the metadata content

   The metadata contains a valid SSH public key for user 'user' under 'ssh-keys'.

2. Step 2: Understand SSH key usage

   When connecting as 'user', the VM checks the 'ssh-keys' metadata and allows access if the matching private key is used.

3. Final Answer:

   SSH connection will succeed using the provided public key -> Option A

4. Quick Check:

   Valid SSH key in metadata = successful SSH login [OK]

Hint: Valid SSH key in metadata allows login [OK]

Common Mistakes:

• Assuming password prompt appears despite key presence
• Thinking VM restarts due to SSH metadata

4. You added an SSH key to your project-wide metadata but still cannot SSH into a VM instance. What is the most likely cause?

medium

A. The firewall allows SSH traffic

B. The VM instance is turned off

C. The instance has block-project-ssh-keys set to true, blocking project keys

D. The SSH key format is incorrect in the metadata

Solution

1. Step 1: Understand project-wide SSH keys

   Project-wide SSH keys apply to all instances unless blocked by instance settings.

2. Step 2: Check instance metadata blocking

   If the instance metadata has 'block-project-ssh-keys' set to true, it ignores project-wide keys.

3. Final Answer:

   The instance has block-project-ssh-keys set to true, blocking project keys -> Option C

4. Quick Check:

   block-project-ssh-keys=true blocks project keys [OK]

Hint: Check 'block-project-ssh-keys' flag on instance [OK]

Common Mistakes:

• Assuming firewall allows SSH means keys work
• Ignoring instance-level metadata blocking project keys

5. You want to ensure that only specific users can SSH into a VM instance in GCP, even though project-wide SSH keys exist. Which approach is best?

hard

A. Add all users' SSH keys to project metadata and leave instance metadata empty

B. Set 'block-project-ssh-keys' to true on the instance and add allowed users' keys to instance metadata

C. Remove all SSH keys from project metadata and rely on firewall rules

D. Disable SSH access entirely on the VM instance

Solution

1. Step 1: Understand project-wide vs instance metadata

   Project-wide SSH keys apply to all instances unless blocked by instance settings.

2. Step 2: Control access per instance

   Setting 'block-project-ssh-keys' to true on the instance disables project keys, allowing only instance metadata keys.

3. Step 3: Add allowed users' keys to instance metadata

   By adding only allowed users' keys to instance metadata, you restrict SSH access to them.

4. Final Answer:

   Set 'block-project-ssh-keys' to true on the instance and add allowed users' keys to instance metadata -> Option B

5. Quick Check:

   Block project keys + instance keys = controlled SSH access [OK]

Hint: Block project keys, use instance keys for control [OK]

Common Mistakes:

• Relying only on firewall rules for SSH user control
• Removing project keys without adding instance keys
• Disabling SSH entirely when access is needed