This scenario requires granting a principal (the service account from proj-sa) permissions to act on resources (VM disks) in a different project (proj-vm). The standard Google Cloud method for cross-project authorization is to grant the principal an Identity and Access Management (IAM) role on the project containing the resources. The Compute Storage Admin (roles/compute.storageAdmin) role contains the necessary permissions, such as compute.disks.createSnapshot, to manage storage resources like persistent disks and snapshots. By granting this role to the service account on the proj-vm project, you authorize it to perform the required actions.

A. Storing private keys in custom metadata is a significant security risk and does not grant the necessary cross-project permissions (authorization) for the service account to act on resources in another project.

B. Service account private keys are used for authenticating to Google Cloud APIs, not for user SSH access. SSH keys are a completely different authentication mechanism for interactive logins.

D. API scopes are a legacy authorization method that defines the maximum permissions for a service account attached to a VM. The primary and more granular method is IAM. This option fails to address the core requirement of granting the service account permissions in the target project (proj-vm).

1. Google Cloud Documentation

"Granting roles to service accounts": In the section "Granting a role to a service account for a project and resources within the project

" the documentation states

"To allow a service account to access resources in a different project

you can grant a role to the service account on the other project." This directly supports the cross-project IAM binding described in the correct answer.

2. Google Cloud Documentation

"IAM basic and predefined roles reference"

Compute Engine roles: The documentation for the Compute Storage Admin role (roles/compute.storageAdmin) confirms that it provides "Full control of Compute Engine storage resources

" which includes permissions for creating snapshots (compute.disks.createSnapshot).

3. Google Cloud Documentation

"Service accounts overview": This document clarifies that a service account is a principal

or an identity

which can be granted IAM roles to access resources. This reinforces the concept of treating the service account from proj-sa as an identity that needs permissions in proj-vm.

4. Google Cloud Documentation

"Access control for Compute Engine resources": This page contrasts IAM and API Scopes

stating

"In general

we recommend using IAM to manage access to Compute Engine resources instead of access scopes." This explains why relying on API scopes (Option D) is not the recommended or correct primary approach.