GCP Professional Cloud Architect Practice Question

Your company's Google Cloud organization (orgA) is acquiring startup orgB. About 30 production projects must move from orgB into orgA. Requirements: 1) orgB engineers keep Project Owner rights on their migrated projects; 2) the enterprise security team must enforce a ban on external IPv4 addresses for all production projects, without affecting development projects; 3) only the Cloud Foundation team may move projects and folders; 4) development-specific IAM bindings must not propagate to production. Which design meets all requirements with minimal ongoing administration?

Create a single Migrated-Projects folder under orgA, move all orgB projects there, enforce the external-IP ban with shared-VPC firewall rules, inherit Development folder IAM to the new folder, and grant orgB engineers project-level owner via a folder-level binding.
Place all migrated projects directly under orgA. Apply compute.vmExternalIpAccess=DENY at the organization root, grant the Cloud Foundation team the Owner role on orgA to move projects, and leave Development folder IAM unchanged.
Create sibling folders named Production and Development under orgA. Grant the Cloud Foundation team roles/resourcemanager.projectMover on orgA. Move all orgB production projects into the Production folder. Apply the compute.vmExternalIpAccess=DENY constraint at the Production folder. Re-grant orgB engineers roles/resourcemanager.projectOwner on each migrated project.
Keep orgB as a subfolder inside a new Production folder. Apply the external-IP deny policy individually to every project. Give Cloud Foundation roles/resourcemanager.folderAdmin on that folder and remove Development IAM bindings from each project manually.

Report Issue

Answer Description

Creating two peer folders-Production and Development-under the orgA root cleanly separates environments, so IAM bindings set for Development never flow into Production. Setting the compute.vmExternalIpAccess organization-policy constraint to DENY at the Production folder enforces the external-IP ban only for production resources and is automatically inherited by every existing or future project moved there. Granting the Cloud Foundation team roles/resourcemanager.projectMover at the organization level gives them exactly the permissions needed to move projects and folders without broader administrative power. Finally, keeping the orgB engineer group's roles/resourcemanager.projectOwner bindings at each migrated project level preserves their ownership while avoiding unnecessary inheritance. The other options either apply security constraints too broadly, require per-project policy maintenance, leak Development IAM into Production, or give the Cloud Foundation team excessive privileges.

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.