Google ACE Practice Question: Your security team wants to prevent any user or…

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 IAM deny policies that prevent the `compute.firewalls.create` permission across the organization.

  Why it's wrong here

  Granting an IAM deny policy to prevent `compute.firewalls.create` at the organization level is far too blunt: it blocks all firewall rule creation in every project, including legitimate internal-only rules that tighten security. IAM permissions are identity-based access controls, not traffic-filtering controls, and they cannot distinguish a rule with source 0.0.0.0/0 from one with source 10.0.0.0/8. This approach would break normal firewall management workflows and still does not stop propagation of already-existing bad rules.

• ✓

  Apply a hierarchical firewall policy at the organization level with a deny rule for ingress from 0.0.0.0/0, set to take precedence over project rules.

  Why this is correct

  A hierarchical firewall policy applied at the organization level with a deny rule for ingress from 0.0.0.0/0 is the correct preventive control. Hierarchical firewall policies are evaluated before VPC firewall rules, and a deny rule in such a policy takes precedence over any project-level allow rule, regardless of that allow rule's priority. By setting the policy's association scope to the organization and giving the deny rule a sufficiently high precedence, all inbound traffic from the public internet is blocked across every project in the organization, and no project administrator can override it with a per-project firewall rule.

• ✗

  Use Security Command Center to detect and alert when 0.0.0.0/0 firewall rules are created.

  Why it's wrong here

  Security Command Center (SCC) can continuously detect configurations that allow public ingress and can emit findings or trigger alerts, but it is a detection-and-response service, not an enforcement point. SCC does not block the API call that creates the firewall rule; it only identifies the rule after it exists. Since the question asks for a preventive control, SCC falls short even though it is useful for visibility and remediation tracking.

• ✗

  Set the `compute.skipDefaultNetworkCreation` org policy constraint across the organization.

  Why it's wrong here

  The `compute.skipDefaultNetworkCreation` org policy constraint only prevents the automatic creation of the default VPC network (and its default firewall rules) when new projects are provisioned. It has no effect on existing networks or on firewall rules manually created in custom VPCs. An administrator could still add an ingress rule allowing 0.0.0.0/0 in any project's VPC, so this constraint does not prevent the problematic pattern.

Go deeper

Related to this question