GCP Professional Cloud Security Engineer Practice Question

Your company has a Google Cloud organization containing hundreds of projects across several folders. A new compliance requirement mandates that no VM instances may obtain external IPv4 addresses anywhere in the organization, except in the following situations:

A hardened bastion host that runs under the service account [email protected] in project sec-bastion must keep its existing external IP so that on-call engineers can SSH into production networks.
Developers working in project api-dev may continue to create or update any VM instances with external IPv4 addresses for integration testing.

You are asked to design an Organization Policy solution that enforces the new rule set with the fewest policy bindings to create and maintain. Which approach meets the requirements while following the principle of least privilege?

Disable the Compute Engine default service account across the Organization, then create custom IAM roles in project api-dev that include compute.instances.setExternalIp and grant the role to developers.
At the Organization level, leave the constraint unenforced. Create folder-level policies that deny external IPs everywhere except the folder that contains api-dev, and attach an allowed list for the bastion host on every production project.
Set constraints/compute.vmExternalIpAccess to Deny all at the Organization level, then add the single allowed value serviceAccount:[email protected] in the same policy. On project api-dev, override the same constraint and set it to Allow all.
Apply a policy at the Organization root that denies external IPs for all VM instances unless they have the network tag allow-external-ip. Attach the tag to the bastion host and to every instance in project api-dev that needs an external IP.

Report Issue

Answer Description

The constraints/compute.vmExternalIpAccess list-based Organization Policy controls which VM instances may possess an external IPv4 address.

By applying a Deny-all policy for this constraint at the Organization level, you immediately block external IP use for every descendant resource.
Because the bastion host must retain its address everywhere, you can still comply by supplying a single allowed value that references the bastion's service account. When a list constraint has allowed values, only the listed identities may receive the restricted capability; every other VM remains denied.
The developers in api-dev need an unrestricted exception only for their own project. Overriding the constraint on that project and setting policy: ALLOW_ALL (the opposite of the org-level rule) lets the team assign external IPs freely, without changing policies for other projects.

This two-layer approach (one org-level policy and one project-level override) satisfies the compliance mandate, keeps administration minimal, and limits exposure precisely to the required resources.

Distractor explanations:

Creating per-folder or per-instance overrides increases operational overhead and is not needed.
Using network tags alone cannot exempt an individual VM across all zones because the list constraint evaluates service accounts or instance references, not tags only.
Turning enforcement off at the Organization level negates the mandate entirely and would rely on every project owner to set explicit denies, which is error-prone.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.