An enterprise is deploying an automated data processing service on Compute Engine instances in Google Cloud. The application requires read-only access to files in a dedicated Cloud Storage bucket (company-data-prod) and permission to publish messages to a specific Pub/Sub topic (data-processed-topic). The security architect must adhere to the following governance requirements: Prevent the use of the default Compute Engine service account and avoid granting basic roles. Enforce the principle of least privilege using fine-grained resource-level IAM bindings rather than coarse-grained VM access scopes or broad project-level roles. Allow the DevOps deployment engineers to attach this identity to Compute Engine instances without granting them permission to impersonate all service accounts across the project. Which configuration meets these requirements?

Create a user-managed service account; grant it roles/storage.objectViewer on the specific Cloud Storage bucket and roles/pubsub.publisher on the specific Pub/Sub topic; grant the DevOps team roles/iam.serviceAccountUser on that specific service account; and attach it to the VM with the cloud-platform access scope.: ### What this solution is This architecture employs a dedicated **user-managed service account** configured with fine-grained, resource-level IAM bindings and utilizes role-scoped impersonation permissions for operational deployment. ### How it meets the requirements - **Distinguishing from default service accounts:** By creating a dedicated **user-managed service account**, the workload is decoupled from the **Compute Engine default service account**, which inherently carries excessive baseline privileges (such as the legacy `roles/editor` role). - **Enforcing least privilege via fine-grained IAM bindings:** Granting **`roles/storage.objectViewer`** directly on the `company-data-prod` bucket and **`roles/pubsub.publisher`** directly on the `data-processed-topic` Pub/Sub topic restricts API access to only the specific target resources and operations required, completely avoiding broad project-wide roles. - **Avoiding coarse access scopes:** Setting the VM access scope to `https://www.googleapis.com/auth/cloud-platform` (full API access) delegates authorization entirely to IAM allow policies rather than relying on coarse-grained, bucket-agnostic OAuth access scopes. - **Scoped service account attachment:** Granting **`roles/iam.serviceAccountUser`** directly on the resource level of the custom service account (rather than project-wide) allows DevOps engineers to attach only this specific identity to instances without exposing other project identities to unauthorized impersonation. ### Key advantages and capabilities - **Resource-level granularity:** Restricts read/write blast radiuses to individual buckets and messaging topics. - **Separation of administrative duties:** Restricts deployment staff to only managing authorized workload identities. - **Auditability:** Isolates logging and telemetry in Cloud Audit Logs to an explicit identity. - **Elimination of privilege creep:** Avoids sharing monolithic service accounts across unrelated workloads. ### Why this is optimal Binding predefined least-privilege roles directly at the target resource level and scoping the `roles/iam.serviceAccountUser` binding to the service account resource itself enforces zero trust and least-privilege governance across both the runtime environment and administrative workflows.

Least Privilege Service Account Iam Configuration | Professional Cloud Security Engineer

Least Privilege Service Account Iam Configuration

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.

An enterprise is deploying an automated data processing service on Compute Engine instances in Google Cloud. The application requires read-only access to files in a dedicated Cloud Storage bucket (company-data-prod) and permission to publish messages to a specific Pub/Sub topic (data-processed-topic).

The security architect must adhere to the following governance requirements:

Prevent the use of the default Compute Engine service account and avoid granting basic roles.
Enforce the principle of least privilege using fine-grained resource-level IAM bindings rather than coarse-grained VM access scopes or broad project-level roles.
Allow the DevOps deployment engineers to attach this identity to Compute Engine instances without granting them permission to impersonate all service accounts across the project.

Which configuration meets these requirements?

Use the Compute Engine default service account; configure VM access scopes to restrict access to Storage Read-Only and Pub/Sub Publisher; and grant the DevOps team roles/iam.serviceAccountUser at the project level.

Create a user-managed service account; assign roles/storage.admin and roles/pubsub.admin at the project level; grant the DevOps team roles/iam.serviceAccountUser at the project level; and configure domain-wide delegation.

Create a user-managed service account; grant it roles/editor at the project level; grant the DevOps team roles/iam.serviceAccountTokenCreator on the service account; and attach it using default access scopes.

Create a user-managed service account; grant it roles/storage.objectViewer on the specific Cloud Storage bucket and roles/pubsub.publisher on the specific Pub/Sub topic; grant the DevOps team roles/iam.serviceAccountUser on that specific service account; and attach it to the VM with the cloud-platform access scope.

Professional Cloud Security Engineer

Least Privilege Service Account Iam Configuration

Related questions