Google ACE Configuring Access and Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Grant roles/owner at the folder level

  Why it's wrong here

  Granting roles/owner at the folder level is incorrect because the owner role is a basic role that provides full administrative control over all resources and IAM policies in every project under the folder. Someone with this role could modify IAM bindings, delete projects, manage all services, and access all data, which is far more than is required to manage firewall rules. This violates the principle of least privilege and creates an unnecessary security risk, especially for a task as narrow as administering firewall rules.

• ✗

  Grant roles/compute.admin at the project level for each project

  Why it's wrong here

  Granting roles/compute.admin at the project level for each project is incorrect because compute.admin is a comprehensive role that includes all Compute Engine permissions, including the ability to create and delete instances, manage images, disks, snapshots, and networks, and even administer IAM on Compute Engine resources. While it does include firewall permissions, it is excessively broad for firewall-only management. Additionally, applying this role per project is inefficient and error-prone, as you must configure it for every existing project and remember to update it whenever a new project is added, unlike a single folder-level grant.

• ✗

  Grant roles/compute.networkAdmin at the folder level

  Why it's wrong here

  Granting roles/compute.networkAdmin at the folder level is wrong because the compute.networkAdmin role, while allowing management of networks, subnets, routes, and other networking resources, does NOT include permissions to create or modify firewall rules (compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete). The role's permission list omits firewall rule operations, so the grant would not accomplish the goal of managing firewall rules. This is a common confusion because firewall rules are related to networking, but in the IAM role hierarchy they fall under the securityAdmin role, not networkAdmin.

• ✓

  Grant roles/compute.securityAdmin at the folder level

  Why this is correct

  Granting roles/compute.securityAdmin at the folder level is the most precise solution because this role includes the compute.firewalls.create, compute.firewalls.update, and compute.firewalls.delete permissions needed to manage firewall rules, but does not include broader permissions to manage instances, networks, or IAM. IAM policies at the folder level are inherited by all projects and resources within that folder, so this single binding covers every descendant project, including newly created ones. This follows least privilege by granting exactly the permissions needed for firewall rule management and nothing extra.

Go deeper

Related to this question