A multinational financial enterprise is designing its cloud compliance and security operations framework on Google Cloud. The compliance team requires strict adherence to the Google Cloud shared responsibility model regarding Identity and Access Management (IAM), incident response, and service-to-service automation. During a compliance audit of their project baseline configurations, the security team identifies the following conditions: Automated pipeline service accounts and human operators have been granted service agent roles (such as roles/securitycenter.securityResponseServiceAgent and roles/cloudsql.admin) to perform routine operations. Default service accounts are being used across compute and database resources without customized IAM boundaries. Which operational governance action should the security team implement to align with shared responsibility and least privilege principles?

Revoke service agent roles from all user principals and pipeline service accounts, create user-managed service accounts with purpose-specific granular predefined or custom roles, and restrict service agent roles exclusively to Google-managed service agents.: ### What the solution is Under the **Google Cloud shared responsibility model**, IAM configuration and access governance are strictly the customer's operational responsibility. Google manages the internal infrastructure and provides pre-configured **service agents** (internal service accounts used by Google Cloud services to run background tasks on behalf of customer projects). Service agent roles contain internal permissions explicitly tailored for Google-managed services and must not be assigned to user-managed principals or pipeline automation accounts. ### How it meets the requirements - **Service agent boundary enforcement:** Removing service agent roles (such as `roles/securitycenter.securityResponseServiceAgent`) ensures internal platform delegation privileges are not inadvertently assigned to standard identities. - **Least privilege access:** Transitioning human users and continuous delivery pipelines to purpose-specific, user-managed service accounts equipped with granular predefined roles (e.g., `roles/cloudsql.admin` only when database administrative delegation is strictly needed) enforces least privilege. - **Compliance alignment:** Properly distinguishing between customer-managed identities and Google-managed platform automation satisfies regulatory audit controls for non-repudiation and access governance. ### Key advantages - **Mitigates privilege escalation:** Prevents user or CI/CD principals from executing hidden or excessive backend service permissions embedded within internal service agent definitions. - **Granular auditability:** Ensures Cloud Audit Logs accurately identify whether an action was performed by an autonomous Google service agent or a customer-initiated workflow. - **Enforces separation of duties:** Establishes clear boundaries between cloud provider infrastructure automation and tenant-managed identity lifecycles. ### Why this is optimal This approach restores the correct security boundary defined by the shared responsibility model. It prevents misconfigured identity assignments from bypassing least-privilege controls while allowing Google-managed backend workflows to operate normally through their native service agents.

Iam Shared Responsibility Service Agent Governance | Professional Cloud Security Engineer

Iam Shared Responsibility Service Agent Governance

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 multinational financial enterprise is designing its cloud compliance and security operations framework on Google Cloud. The compliance team requires strict adherence to the Google Cloud shared responsibility model regarding Identity and Access Management (IAM), incident response, and service-to-service automation.

During a compliance audit of their project baseline configurations, the security team identifies the following conditions:

Automated pipeline service accounts and human operators have been granted service agent roles (such as roles/securitycenter.securityResponseServiceAgent and roles/cloudsql.admin) to perform routine operations.
Default service accounts are being used across compute and database resources without customized IAM boundaries.

Which operational governance action should the security team implement to align with shared responsibility and least privilege principles?

Delegate full identity lifecycle management to Google by enabling automatic service agent impersonation on all Compute Engine default service accounts.

Retain the assigned service agent roles across all automation pipelines, but apply Customer-Managed Encryption Keys (CMEK) to encrypt service account credentials and project metadata.

Assign basic Owner and Editor roles to deployment pipeline identities to ensure all underlying service agent permissions are superseded and unified.

Revoke service agent roles from all user principals and pipeline service accounts, create user-managed service accounts with purpose-specific granular predefined or custom roles, and restrict service agent roles exclusively to Google-managed service agents.

Professional Cloud Security Engineer

Iam Shared Responsibility Service Agent Governance

Related questions