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.