Bird
Raised Fist0
GCPcloud~5 mins

SSH access and metadata in GCP - Cheat Sheet & Quick Revision

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is SSH access in Google Cloud Platform (GCP)?
SSH access allows you to securely connect to your virtual machine (VM) instances in GCP using a command-line interface over the internet or internal network.
Click to reveal answer
beginner
What role does metadata play in managing SSH access on GCP VM instances?
Metadata stores SSH keys and other configuration data that GCP uses to control access and settings for VM instances.
Click to reveal answer
intermediate
How can you add an SSH key to a GCP VM instance using metadata?
You add the SSH public key to the instance or project metadata under the 'ssh-keys' entry, allowing the corresponding private key holder to connect.
Click to reveal answer
intermediate
What is the difference between project-wide and instance-level SSH keys in GCP metadata?
Project-wide SSH keys apply to all VM instances in the project, while instance-level keys apply only to a specific VM instance.
Click to reveal answer
beginner
Why is it important to manage SSH keys carefully in GCP metadata?
Because SSH keys control who can access your VMs, managing them carefully helps keep your cloud resources secure and prevents unauthorized access.
Click to reveal answer
Where do you add SSH keys to allow access to all VM instances in a GCP project?
AIn the project-wide metadata under 'ssh-keys'
BIn the instance's boot disk
CIn the firewall rules
DIn the Cloud Storage bucket
What does SSH stand for?
ASecure System Handler
BSimple Secure Host
CServer Shell Host
DSecure Shell
If you want to restrict SSH access to only one VM instance, where should you add the SSH key?
AIn the Cloud IAM roles
BIn the project-wide metadata
CIn the instance-level metadata
DIn the VPC network settings
What is the purpose of the SSH public key in GCP metadata?
ATo identify the user allowed to connect to the VM
BTo encrypt the VM's disk
CTo configure the VM's firewall
DTo start the VM instance
Which of the following is NOT a recommended practice for SSH key management in GCP?
ARegularly rotating SSH keys
BSharing private SSH keys with others
CRemoving unused SSH keys from metadata
DUsing instance-level keys for sensitive VMs
Explain how SSH access is controlled using metadata in GCP.
Think about where SSH keys are stored and how they grant access.
You got /3 concepts.
    Describe best practices for managing SSH keys in GCP metadata to keep your VMs secure.
    Consider security steps to prevent unauthorized access.
    You got /4 concepts.

      Practice

      (1/5)
      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... user@example.com"}

      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