Sample questions
Gcp Iam SecurityDifficulty 1
In GCP's resource hierarchy, what is the correct top-to-bottom containment order?
- aFolder > Organization > Project > Resource
- bOrganization > Folder > Project > Resource✓
- cProject > Organization > Folder > Resource
- dOrganization > Project > Folder > Resource
Explanation:GCP's resource hierarchy runs Organization at the top, containing zero or more Folders, which contain Projects, which contain individual resources (VMs, buckets, etc.). Folders are optional grouping nodes between Organization and Project, not the other way around.
Gcp Iam SecurityDifficulty 1
An IAM allow policy grants roles/viewer at the Folder level. What happens to Projects inside that Folder by default?
- aThe permission is inherited downward; every Project (and its resources) in the Folder also grants that access✓
- bNothing happens; IAM policies never apply below the level where they are set
- cEach Project must separately re-grant the same role for it to take effect
- dThe policy only applies to the Folder's own metadata, not to Projects inside it
Explanation:GCP IAM allow policies are inherited down the resource hierarchy: a binding at the Folder level automatically applies to every Project and resource nested underneath it, without needing to be re-granted at each lower level.
Gcp Iam SecurityDifficulty 2
A team wants to remove a permission that a Project inherited from its parent Folder's allow policy, by editing only the Project's own IAM policy. Is this possible?
- aYes, removing the binding from the Project's policy always overrides the inherited one
- bYes, but only for predefined roles, not custom roles
- cNo — a standard allow policy at the Project level cannot revoke access granted by an ancestor; that requires a separate IAM Deny policy✓
- dNo, inherited permissions can never be revoked at any level under any circumstances
Explanation:Ordinary IAM allow policies are purely additive down the hierarchy — editing a descendant's own allow policy cannot strip away access granted by an ancestor. To explicitly block access regardless of ancestor grants, GCP provides a separate mechanism (IAM Deny policies) rather than relying on the allow policy itself.
Gcp Iam SecurityDifficulty 1
What best describes the difference between a predefined IAM role and a custom IAM role in GCP?
- aPredefined roles can only be applied to Projects; custom roles can only be applied to Organizations
- bCustom roles automatically gain new permissions whenever Google adds them to a similar predefined role over time
- cPredefined roles cannot be bound to service accounts, only custom roles can
- dPredefined roles are curated by Google and can change over time; custom roles only change when manually updated✓
Explanation:Predefined roles (e.g. roles/compute.viewer) are managed by Google, and their permission set can be updated by Google over time. Custom roles let a user assemble their own exact set of permissions from a supported list, and that set stays fixed until someone manually edits the custom role definition.
Gcp Iam SecurityDifficulty 2
A team creates a custom role containing only storage.objects.get and storage.objects.list. Compared to granting roles/storage.objectViewer (a predefined role with the same two permissions today), what is the practical tradeoff?
- aThe custom role's permission set is frozen as-is; if Google later adds a related permission to
objectViewer, the custom role won't automatically gain it, requiring manual maintenance✓ - bThere is no difference at all; GCP treats custom roles with identical permissions as aliases of the matching predefined role
- cThe custom role will always cost more to evaluate at policy-check time than the predefined role
- dCustom roles can only be granted to users, never to service accounts, unlike predefined roles
Explanation:Even if a custom role starts with the exact same permissions as a predefined role, it is a separate, static definition. Google can evolve predefined roles' permission sets over time; a custom role stays exactly as defined until someone manually updates it, which is the real ongoing maintenance cost of using custom roles.
Gcp Iam SecurityDifficulty 2
Why can't every IAM permission be included in a custom role?
- aCustom roles have a hard limit of 5 permissions per role
- bOnly permissions used by fewer than 3 predefined roles are eligible to be added to a custom role
- cOnly permissions marked as supporting custom roles can be added✓
- dEvery permission can be included; there is no restriction on custom role composition
Explanation:Google publishes a list of permissions that support custom roles. Not all permissions qualify — some are tied to specific predefined-role semantics or internal implementation details that don't make sense to expose piecemeal, so custom roles can only be assembled from that supported subset.