A financial enterprise is hardening its Compute Engine infrastructure in Google Cloud. Security auditors found that developers have excessive privileges that allow them to view and modify sensitive custom instance metadata keys and deploy instances using privileged workload identities. The security engineer must implement least-privilege access controls with the following requirements: Developers must be allowed to inspect instance details and read custom instance metadata from outside the VM using the Google Cloud CLI or REST API for troubleshooting. Developers must be strictly prevented from modifying VM metadata, updating startup scripts, or deploying/attaching the VM's user-managed service accounts (iam.serviceAccounts.actAs). Workloads running inside the VM instances must adhere to Google Cloud best practices for service account authorization and API access scopes. Which configuration should the security engineer implement?

Grant developers a role with `compute.instances.get` on the VM instances, do not grant `roles/iam.serviceAccountUser`, and set the `https://www.googleapis.com/auth/cloud-platform` access scope on instances while restricting workload permissions strictly via IAM roles on the attached service account.: ### What this solution is This solution implements granular Identity and Access Management (**IAM**) permissions for administrators and developers outside the virtual machine while applying Google Cloud best practices for workload identities and API access scopes on Compute Engine instances. ### How it meets the requirements - **Inspect instance details and custom metadata:** The `compute.instances.get` permission allows principals to retrieve instance metadata and configuration properties via the Google Cloud CLI, Console, or REST API without granting write permissions. - **Prevent metadata modification and identity impersonation:** By withholding the `roles/iam.serviceAccountUser` role (which grants `iam.serviceAccounts.actAs`) and omitting `compute.instances.setMetadata`, developers cannot alter metadata scripts or launch/modify resources acting as the service account. - **Workload authorization best practice:** Setting the comprehensive `https://www.googleapis.com/auth/cloud-platform` access scope on VM instances delegates all authorization enforcement directly to IAM roles assigned to the user-managed service account, avoiding restrictive and inflexible legacy OAuth scope configurations. ### Key advantages and capabilities - **Principle of least privilege:** Separates read access to instance metadata from control-plane administrative capabilities. - **Prevents privilege escalation:** Disallowing `iam.serviceAccounts.actAs` prevents unauthorized users from leveraging service account permissions bound to the VM. - **Centralized permission governance:** Using the full `cloud-platform` scope ensures IAM allow policies remain the single source of truth for application resource access. - **Operational visibility:** Allows troubleshooting and metadata inspection without compromising infrastructure configuration integrity. ### Why this is optimal This approach aligns with Google Cloud architecture best practices by isolating metadata read operations from write/execution operations and centralizing application permission management in IAM rather than relying on double-filtering access scopes.

Secure Compute Vm Metadata Iam Scopes | Professional Cloud Security Engineer

Secure Compute Vm Metadata Iam Scopes

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A financial enterprise is hardening its Compute Engine infrastructure in Google Cloud. Security auditors found that developers have excessive privileges that allow them to view and modify sensitive custom instance metadata keys and deploy instances using privileged workload identities.

The security engineer must implement least-privilege access controls with the following requirements:

Developers must be allowed to inspect instance details and read custom instance metadata from outside the VM using the Google Cloud CLI or REST API for troubleshooting.
Developers must be strictly prevented from modifying VM metadata, updating startup scripts, or deploying/attaching the VM's user-managed service accounts (iam.serviceAccounts.actAs).
Workloads running inside the VM instances must adhere to Google Cloud best practices for service account authorization and API access scopes.

Which configuration should the security engineer implement?

Grant developers roles/compute.securityAdmin on the project, assign iam.serviceAccounts.actAs directly to developers on the project root, and disable the metadata server via firewall rules.

Grant developers roles/compute.viewer combined with roles/iam.serviceAccountAdmin on the service account, and enforce access tokens with https://www.googleapis.com/auth/devstorage.read_only scope.

Grant developers the predefined roles/compute.instanceAdmin.v1 and roles/iam.serviceAccountUser roles at the project level, and configure VM instances with the restricted https://www.googleapis.com/auth/compute.readonly access scope.

Grant developers a role with compute.instances.get on the VM instances, do not grant roles/iam.serviceAccountUser, and set the https://www.googleapis.com/auth/cloud-platform access scope on instances while restricting workload permissions strictly via IAM roles on the attached service account.

Professional Cloud Security Engineer

Secure Compute Vm Metadata Iam Scopes

Related questions