Google Associate Cloud Engineer

Get started today

Ultimate access to all questions.

Explanation:

Option A is correct because enabling OS Login via the metadata “enable-oslogin=true” and granting the compute.osLogin role to the dev-1 group ensures that members can only access their designated VM without broader project access. Using Cloud Shell for SSH connections adds a layer of security. Options B, C, and D are incorrect due to unnecessary steps (B), security risks associated with manual key distribution (C), and lack of access restriction to other project resources (D).

Explanation:

Comments (0)

No comments yet.

You are managing a multi-tier gaming application on Compute Engine. A VM within this stack is managed by another team, dev-1, who has requested SSH access to their VM in your GCP project. Your goal is to ensure dev-1 team members can only access their VM and no other resources in the project. What is the best approach to configure this access?

Real Exam

Set the instance metadata to “enable-oslogin=true”. 2. Assign the compute.osLogin role to the dev-1 group. 3. Instruct dev-1 team members to use Cloud Shell for SSH access to the VM.

70.6%

Set the instance metadata to “enable-oslogin=true”. 2. Ensure the instance's service account is set to no service account. 3. Have dev-1 team members use Cloud Shell to SSH into the instance.

5.9%

Activate block project-wide keys for the instance. 2. Create a unique SSH key for each dev-1 group member. 3. Manually provide these keys to dev-1 users for VM access via putty.

17.6%

Activate block project-wide keys for the instance. 2. Generate an SSH key linked to the instance. 3. Share this key with dev-1 users for VM access via putty.