Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise organization is establishing a centralized Shared VPC architecture to host workloads across multiple departments. The central network security team manages the Shared VPC host project, which contains subnet-frontend (in us-central1), subnet-backend (in us-central1), and subnet-analytics (in us-east1).
The organization must meet the following access and administrative requirements:
service-project-app and must only be able to provision VM instances into subnet-frontend.service-project-data and must only be able to provision VM instances into subnet-analytics.How should IAM roles and resource bindings be configured to meet these requirements following the principle of least privilege?
Assign the Shared VPC Admin (roles/compute.xpnAdmin) role to the AppDev and Analytics teams on the host project. Assign the central network team Security Admin (roles/compute.securityAdmin) on the host project.
Assign the AppDev team and Analytics team Compute Network User (roles/compute.networkUser) at the host project level, while restricting subnet selection via IAM conditions on Compute Instance Admin in each service project. Assign the central network team Compute Admin (roles/compute.admin) on both the host and service projects.
Assign the AppDev team and Analytics team Compute Network Admin (roles/compute.networkAdmin) in their respective service projects. Use VPC Network Peering to connect each service project's local VPC back to the host project's Shared VPC.
Assign the AppDev team Compute Instance Admin on service-project-app and Compute Network User (roles/compute.networkUser) specifically on the subnet-frontend resource in the host project. Assign the Analytics team Compute Instance Admin on service-project-data and Compute Network User specifically on the subnet-analytics resource in the host project. Assign the central network team Compute Network Admin (roles/compute.networkAdmin) at the host project level.
Assign the Shared VPC Admin (roles/compute.xpnAdmin) role to the AppDev and Analytics teams on the host project. Assign the central network team Security Admin (roles/compute.securityAdmin) on the host project.
Assign the AppDev team and Analytics team Compute Network User (roles/compute.networkUser) at the host project level, while restricting subnet selection via IAM conditions on Compute Instance Admin in each service project. Assign the central network team Compute Admin (roles/compute.admin) on both the host and service projects.
Assign the AppDev team and Analytics team Compute Network Admin (roles/compute.networkAdmin) in their respective service projects. Use VPC Network Peering to connect each service project's local VPC back to the host project's Shared VPC.
Assign the AppDev team Compute Instance Admin on service-project-app and Compute Network User (roles/compute.networkUser) specifically on the subnet-frontend resource in the host project. Assign the Analytics team Compute Instance Admin on service-project-data and Compute Network User specifically on the subnet-analytics resource in the host project. Assign the central network team Compute Network Admin (roles/compute.networkAdmin) at the host project level.
Shared VPC enables centralized management of networking infrastructure by separating host projects from service projects. Subnet-level access control allows administrators to grant the Compute Network User (roles/compute.networkUser) role on individual subnet resources rather than across the entire host project.
roles/compute.networkUser at the individual subnet resource level (e.g., subnet-frontend or subnet-analytics) grants Service Project Admins permission to attach network interfaces and instantiate VMs in that specific subnet only, preventing unauthorized provisioning into other subnets like subnet-backend.roles/compute.instanceAdmin.v1 or similar) in their respective service projects allows developers to manage virtual machines and application workloads autonomously.roles/compute.networkAdmin) to the network team at the host project level provides complete control over routing, peering, subnets, and firewall rules without granting service project workload permissions.Applying the roles/compute.networkUser role directly to target subnets adheres to least privilege by restricting service teams from discovering and deploying into unauthorized subnets, satisfying all architectural and security constraints.