Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A security engineer manages organization policies for an enterprise Google Cloud environment structured with the following resource hierarchy:
StudyCerts
StudyCertsorganizations/1001)
folders/2001)
folders/3001)
dev-backend (projects/4001)eng-shared-tools (projects/4002)The security engineer applies the following organization policy specification at the organization root for a list constraint:
name: organizations/1001/policies/compute.storageResourceUseRestrictions
spec:
rules:
- values:
deniedValues:
- under:folders/2001
No other organization policies or overrides have been applied at any folder or project level.
What is the effective policy evaluation for dev-backend and eng-shared-tools?
Only eng-shared-tools evaluates to denied because the under: prefix applies exclusively to immediate direct children of folders/2001 and does not cascade through nested subfolders.
Both dev-backend and eng-shared-tools evaluate to denied because the under: prefix matches the specified folder and recursively encompasses all descendant subfolders and projects in that subtree.
Both dev-backend and eng-shared-tools evaluate to allowed because list constraints ignore inherited deniedValues unless a local merge policy is explicitly configured on each project.
Neither project evaluates to denied because subtree values using under: are only valid when the organization policy is attached directly to the target folder (folders/2001).
Only eng-shared-tools evaluates to denied because the under: prefix applies exclusively to immediate direct children of folders/2001 and does not cascade through nested subfolders.
Both dev-backend and eng-shared-tools evaluate to denied because the under: prefix matches the specified folder and recursively encompasses all descendant subfolders and projects in that subtree.
under:) AreA hierarchy subtree string is a specialized value format used in Google Cloud list constraints prefixed by under: (such as under:organizations/ID, under:folders/ID, or under:projects/ID). Its primary purpose is to apply policy rules broadly across a logical container and all existing or future child resources rooted beneath it, eliminating the operational overhead of listing every project ID individually.
organizations/1001). By default, child resources inherit policies from their parent containers.folders/2001, folders/3001, eng-shared-tools, nor dev-backend define local overriding policies, they directly inherit the constraint rule from organizations/1001.eng-shared-tools (projects/4002), it detects that the project is an immediate child of folders/2001. For dev-backend (projects/4001), it evaluates ancestry up through folders/3001 to folders/2001. Because both resources reside within the hierarchy subtree rooted at folders/2001, the rule evaluates to denied for both.under: prefix acts on the designated resource and every nested descendant in the subtree, regardless of nesting depth.folders/2001 automatically inherit the denial without requiring policy modifications.In Google Cloud Organization Policy hierarchy evaluation, list constraints evaluate against resource lineage. Because the subtree rule specifies under:folders/2001, all resources descended from folders/2001 inherit and match the denied value.
Both dev-backend and eng-shared-tools evaluate to allowed because list constraints ignore inherited deniedValues unless a local merge policy is explicitly configured on each project.
Neither project evaluates to denied because subtree values using under: are only valid when the organization policy is attached directly to the target folder (folders/2001).