An enterprise financial application running on Google Cloud Compute Engine requires access to database credentials stored in Secret Manager. The security team establishes strict security requirements: The application service account must only be granted permission to retrieve the decrypted secret payload for its specific database secret, without administrative permissions over other secrets. Exfiltration of secret payloads to unauthorized projects or outside the trusted enterprise network perimeter must be strictly prevented. Access to the Secret Manager API must be contained within a defined security boundary that blocks public internet calls. Which combination of access governance and network security controls should you implement to satisfy these requirements?

Grant the application service account the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role bounded strictly to the specific secret resource, add the project to a VPC Service Controls perimeter, and add Secret Manager (secretmanager.googleapis.com) to the perimeter's restricted services.: ### What the solution is This solution combines granular, resource-level **Identity and Access Management (IAM)** with **VPC Service Controls** perimeter security. It grants the least-privilege role required to access payload contents—**Secret Manager Secret Accessor** (`roles/secretmanager.secretAccessor`)—directly on the targeted secret resource rather than at the project or folder level, while restricting API access inside a VPC Service Controls boundary. ### How it meets the requirements - **Granular Least Privilege**: By assigning `roles/secretmanager.secretAccessor` exclusively on the target secret, the application service account receives the `secretmanager.versions.access` permission for that specific secret only, preventing it from reading, modifying, or deleting other enterprise secrets. - **Exfiltration Prevention**: VPC Service Controls defines a secure perimeter around the project hosting Secret Manager. If credentials or service account tokens are leaked outside the perimeter, API requests originating from untrusted networks or unapproved projects are automatically rejected. - **Network Containment**: Designating `secretmanager.googleapis.com` as a **restricted service** inside the perimeter ensures that API communication cannot traverse to or from the public internet without explicit ingress/egress policy rules. ### Key advantages and capabilities - **Principle of Least Privilege**: Prevents privilege escalation by separating secret administration (`roles/secretmanager.admin`) from secret consumption (`roles/secretmanager.secretAccessor`). - **Zero Trust Network Boundary**: Mitigates risks associated with stolen OAuth access tokens or service account keys by validating network and perimeter context on every API call. - **Resource-Level IAM Binding**: Limits the blast radius in multi-tenant or shared project architectures by scoping IAM policies to individual secret objects. - **Auditability and Compliance**: Produces complete Cloud Audit Logs capturing access requests while enforcing strict data boundary compliance. ### Why this is optimal This approach aligns with Google Cloud security best practices by uniting identity-based least privilege at the individual resource tier with cryptographic and network perimeter controls via VPC Service Controls. It completely blocks unauthorized internet egress and cross-project data exfiltration while satisfying least-privilege credential requirements.

Secret Manager Iam Vpc Service Controls | Professional Cloud Security Engineer

Secret Manager Iam Vpc Service Controls

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 financial application running on Google Cloud Compute Engine requires access to database credentials stored in Secret Manager. The security team establishes strict security requirements:

The application service account must only be granted permission to retrieve the decrypted secret payload for its specific database secret, without administrative permissions over other secrets.
Exfiltration of secret payloads to unauthorized projects or outside the trusted enterprise network perimeter must be strictly prevented.
Access to the Secret Manager API must be contained within a defined security boundary that blocks public internet calls.

Which combination of access governance and network security controls should you implement to satisfy these requirements?

Grant the application service account the Secret Manager Secret Version Manager (roles/secretmanager.secretVersionManager) role on the project, and enable Private Google Access on the application subnet without a perimeter.

Grant the application service account the Secret Manager Admin (roles/secretmanager.admin) role at the project level, and configure Cloud Armor edge security policies on the Secret Manager regional endpoints.

Grant the application service account the Secret Manager Viewer (roles/secretmanager.viewer) role at the folder level, and enforce Identity-Aware Proxy (IAP) TCP forwarding on the client instances.

Grant the application service account the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role bounded strictly to the specific secret resource, add the project to a VPC Service Controls perimeter, and add Secret Manager (secretmanager.googleapis.com) to the perimeter's restricted services.

Professional Cloud Security Engineer

Secret Manager Iam Vpc Service Controls

Related questions