Google PCA Designing for Security and Compliance Practice Question
A healthcare company runs a multi-tenant SaaS platform on Google Cloud. Each tenant has a dedicated folder inside a single organization, with projects for each environment. A recent audit found that a compromised service account in one tenant's dev project could enumerate and read Cloud Storage buckets belonging to other tenants because the service account had been granted roles/storage.admin at the organization level by mistake. The security team wants a preventive control that blocks any future IAM binding that grants a role to a principal at a scope broader than a single project, unless the principal is part of a small break-glass group. They also want the control to apply automatically to all new projects. What should the architect implement?
⚠ Common exam trap
The trap here is assuming that iam.allowedPolicyMemberDomains or IAM Conditions provide preventive scope guardrails, when domain constraints only limit identity domains and conditions must be attached correctly to every binding.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure an organization policy using a custom constraint on the iam.googleapis.com/AllowPolicy resource, denying bindings where the resource scope is the organization or a folder unless the principal is in the break-glass group.
The requirement is a preventive, hierarchy-wide guardrail against overly broad IAM grants. Custom organization policy constraints on the IAM allow policy resource can inspect both the binding's scope and the principal, so a rule that denies organization- and folder-level grants except for a designated break-glass group enforces least privilege automatically for existing and new projects. Domain-based and condition-based approaches either do not address scope breadth or rely on per-binding correctness, so they would not have prevented the audit finding.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create an organization policy with the iam.allowedPolicyMemberDomains constraint set to the company's Cloud Identity domain, and apply it to the organization node.
Why it's wrong here
This constraint restricts which identity domains can appear in IAM policies, which prevents external principals but does nothing to stop an internal service account from being granted roles/storage.admin at the organization scope. The audit finding is about excessive privilege breadth, not domain membership, so this policy would not have blocked the misconfiguration and would leave cross-tenant access possible.
- ✗
Enable IAM Conditions on all role bindings and require a condition that the resource name matches the tenant's folder path.
Why it's wrong here
IAM Conditions can scope bindings using resource attributes, but they are attached per binding and must be authored correctly each time. A mistaken binding without a condition would still be accepted, so this is not a preventive guardrail. It also does not automatically apply to new projects, and condition authoring errors are exactly the failure mode the audit already exposed.
- ✗
Create an organization policy with the iam.disablePolicyMemberDomainCheck constraint and apply it to the organization node.
Why it's wrong here
This constraint affects whether IAM policy members must belong to a permitted domain; disabling the check loosens controls rather than tightening them. It would not restrict the scope at which roles are granted and could even worsen the exposure by allowing broader principal types. It is unrelated to preventing organization-level grants to service accounts.
- ✓
Configure an organization policy using a custom constraint on the iam.googleapis.com/AllowPolicy resource, denying bindings where the resource scope is the organization or a folder unless the principal is in the break-glass group.
Why this is correct
Custom organization policy constraints can evaluate IAM allow policies and deny bindings based on the resource hierarchy level and the principal. By scoping the constraint to the organization node it is inherited by all current and future projects and folders, blocking the exact misconfiguration that allowed the compromised service account to reach other tenants' buckets while permitting the break-glass group.
Go deeper
Related to this question
Learn chapter
Cloud Storage: Objects and Buckets
Key term
Service account
A service account is a special type of account used by an application or a virtual machine, rather than a human user, to authenticate and interact with cloud services and APIs securely.
Key term
Cloud storage
Cloud storage is a service that lets you save data on remote servers accessed over the internet instead of on your computer's hard drive.
About these practice questions
Courseiva writes every PCA question from scratch — 807 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This PCA practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCA exam.