Get Your CertGoogle Cloud Professional Cloud ArchitectPlayCompete
‹ All Google Cloud Professional Cloud Architect questions

GCP Professional Cloud Architect Practice Question 5: Domain Restricted Sharing Policy

Google Cloud Professional Cloud Architect · Test 1 · question 5 of 10

Security & Complianceeasy

Following an internal audit, a bank discovers that project owners in several teams have granted Editor to personal @gmail.com accounts and to contractors at an unaffiliated domain. The security office wants a control that stops any principal outside the bank's own Cloud Identity domains from being added to an allow policy anywhere in the organization, applied centrally and inherited by every existing and future folder and project.

What should the architect implement?

Select one answer
Show answer and explanation

Answer:

  • B. The iam.allowedPolicyMemberDomains organization policy constraint set at the organization node with the bank's Cloud Identity customer ID in the allowed values

iam.allowedPolicyMemberDomains, domain restricted sharing, is the purpose-built control. It is a list constraint whose allowed values are Cloud Identity or Google Workspace customer IDs (or organization principal sets), and any attempt to add a principal outside those identities to an allow policy is rejected at the API. Set once on the organization node, it is inherited by every folder and project underneath, including ones created later, which is exactly the central, future-proof enforcement the security office asked for. The documentation describes it as restricting principals added after the policy is enforced, so in practice teams also audit existing bindings and remove any that predate it.

Option A is far too blunt. Denying setIamPolicy to everyone but one team stops all delegated access management, legitimate internal grants included, and centralizes routine work in a bottleneck team, without ever expressing the actual rule about *which principals* are acceptable.

Option C does not scale and is not preventive. IAM Conditions are attached per binding, so an owner who adds a new unconditional binding simply bypasses them; conditions also cannot be forced onto grants that have not been made yet.

Option D is detective, not preventive. The data is exposed for the interval between the bad grant and the cleanup function running, and a failure in the pipeline silently leaves the violation in place. It is a reasonable complement to option B, not a substitute for it.

Reference: Restricting identities by domain

Practice Test 1 ›

Study guides for Google Cloud Professional Cloud Architect