In Cloud Identity + SecOps, external Google accounts are added to a group with project-level roles but cannot access SecOps, while internal users can. Which configuration most likely causes this?

• A. External users must be synced to Cloud Identity via GCDS.
• B. SecOps blocks sign-ins from identities outside the primary domain.
• C. constraints/iam.allowedPolicyMemberDomains org policy restricts IAM role assignments to identities within your company domain only.
• D. roles/chronicle.viewer doesn't apply when granted to Google Groups with external identities.

Answer: (C)

The setting being tested is domain-based access control through an Organization Policy. The constraint constraints/iam.allowedPolicyMemberDomains restricts which domains can be used in IAM policy bindings. When this policy is in effect, only identities from approved domains can be granted IAM roles for resources. In this scenario, internal users from the company domain are allowed and can access SecOps, while external Google accounts—though they can be added to a group with project-level roles—do not belong to an allowed domain for SecOps, so their access is blocked. This explains why external accounts can have project-level roles but cannot reach SecOps, whereas internal users can. The other options don’t fit because they describe provisioning, sign-in blocking, or role applicability that doesn’t hinge on domain-based access restrictions for SecOps.