Topic 1 of 5
Resource hierarchy and organization policies
Before you deploy a single virtual machine you have to decide where it lives: in which organization, folder, and project. That structure determines who owns the resources, how permissions are inherited, and which restrictions apply. The exam asks about both the hierarchy and the Organization Policy Service that protects it.
Contents
The resource hierarchy
A tree with the organization as the root, optional folders for grouping, and projects that contain the service resources: virtual machines, buckets, databases.
Every resource except the top one has exactly one parent. Google Cloud highlights two advantages of this structure:
Ownership
A resource's lifecycle is bound to its parent. Projects belong to the organization, not to the employee who created them: if that person leaves, the project stays active.
Inheritance
Allow, deny, and organization policies flow down the tree. A role granted on a folder is inherited by all of its projects.
The effective policy of each resource combines the policies applied directly to it and the ones inherited from its ancestors.
The organization resource
It represents an entity, such as a company, and is the root node. To have one you need a Google Workspace or Cloud Identity account associated with a domain. Each Workspace or Cloud Identity account is associated with exactly one organization, and each organization with exactly one domain.
- It is created automatically when a user from the domain signs in to the console and accepts the terms, or creates a project or billing account with no associated organization.
- Projects created earlier appear under "No organization" and must be migrated manually.
- Once the organization exists, managed users in the domain can only create projects inside it.
- The initial policy grants Project Creator and Billing Account Creator to the whole domain, so nobody notices the change.
- It is identified by a unique numeric ID (no leading zeros) that you get with
gcloud organizations list.
| Role | Responsibilities |
|---|---|
| Workspace or Cloud Identity super administrator | Assigns the Organization Administrator role, is the contact for recovery issues, and controls the lifecycle of the account and the organization. Should not be used for day-to-day administration. |
Organization Administrator (roles/resourcemanager.organizationAdmin) | Defines allow and deny policies, grants roles, and sees the structure. Following least privilege, it can't create folders or projects without additional roles. |
Google recommends that the super administrator delegate the Organization Administrator role to a different user or group to separate duties, because Workspace and Google Cloud are usually managed by different departments.
Standalone organizations
Setting them up is in the exam guide. They are a second way to get an organization without Cloud Identity or a domain: they are created automatically for new Free Trial customers when they sign up with a Google email address and accept the terms. They aren't available for existing Google Cloud accounts.
Name
Username + "-org" (lara_brown → lara-brown-org). It can be changed; it can't be a domain name.
Initial roles
The creator gets Organization Owner (roles/cloudowner.admin, managed outside IAM) and Organization Administrator.
Benefits
Owners with federated identities, multiple organizations for testing, and multiple owners to avoid depending on one person.
- One organization is created per user account, but one user can own several.
- Owners are invited from the Organization details page and must accept within 30 days. They can be Google Accounts or principals in a Workforce Identity Federation pool; service accounts can't.
- At least one active Google Account must always remain as an owner.
- If nobody keeps permission to edit the organization's IAM policy, an Organization Owner can grant Organization Administrator again from that same page.
Folders
An optional grouping mechanism between the organization and projects. They require an organization. They work as sub-organizations: they can represent legal entities, departments, teams, applications, or environments (development, test, production), and they let you delegate administration, for example by giving each department head ownership of everything in their folder.
10 levels
Maximum folder nesting depth.
300 folders
Maximum direct child folders in a parent folder.
gcloud resource-manager folders create \ --display-name=Engineering --organization=ORGANIZATION_ID gcloud resource-manager folders create \ --display-name=Team-A --folder=FOLDER_ID
Google recommends starting with a single sandbox folder to experiment with which hierarchy fits best before building the final one.
Projects
The project is the fundamental organizing entity: you need one to use Google Cloud. It is where you enable APIs, turn on billing, add collaborators, and manage permissions. Whoever creates it gets the Owner role.
| Identifier | Who picks it | Can it change? | Rules |
|---|---|---|---|
| Project name | You | Yes | 4 to 30 characters: letters, numbers, single quotes, hyphens, spaces, or exclamation points |
| Project ID | You (the console suggests one) | No, it is permanent | 6 to 30 characters, starts with a lowercase letter, only ASCII letters, digits, and hyphens. Globally unique and never used before (not even by deleted projects). No strings such as google or ssl |
| Project number | Google, automatically | No, read-only | Numeric |
gcloud projects create PROJECT_ID --organization=ORGANIZATION_ID gcloud projects create PROJECT_ID --folder=FOLDER_ID
- Don't put sensitive information in the name or ID: the ID appears in the names of many other resources.
- Anyone can create projects, including free trial users. Only projects created by free trial or free tier users can sit at the top of their hierarchy without an organization; they can be migrated into one later.
- The number of projects a user or service account can create is limited. Inside an organization, both the user's quota and the organization's quota are checked: if either has room, the project is created.
Shutting down and restoring a project
Shutting down a project stops all billing and resource usage. Only projects in the ACTIVE state can be shut down, and you need the resourcemanager.projects.delete permission.
Immediate shutdown: The project is marked for deletion and becomes unusable.
Notification: An email goes to the user who started the shutdown and to the Technical contacts in Essential Contacts.
Billing: The billing account is disconnected. If the project is restored, the link isn't reinstated automatically.
30 days in DELETE_REQUESTED: Project owners can restore it. It still counts toward the project quota during this time.
Permanent deletion: After 30 days, the project and all its resources are deleted and can't be recovered.
Keep in mind
- Some services, such as Cloud Storage and Pub/Sub, might delete their resources much sooner than 30 days.
- After a restore, some services take up to 36 hours to fully resume.
- The project may keep incurring charges until the end of the billing cycle: disable billing before shutting it down.
- If it has active committed use discounts (CUDs), Google recommends applying project liens to prevent accidental deletion.
Organization Policy Service
It gives centralized, programmatic control over how the organization's resources can be configured. It sets compliance guardrails without slowing teams down. Typical use cases: limit resource sharing by domain, limit the use of service accounts, and restrict the physical location of new resources.
IAM = who
Authorizes who can take action on which resources, through permissions.
Organization Policy = what
Restricts how resources can be configured, no matter who tries.
A constraint is the blueprint that defines which behavior is controlled, for example compute.storageResourceUseRestrictions. An organization policy applies that constraint to an organization, folder, or project, and affects that resource and all its descendants. Each policy enforces exactly one constraint, in active mode, dry-run mode, or both, and is defined in YAML or JSON. The role to manage them is Organization Policy Administrator (roles/orgpolicy.policyAdmin).
Constraint types
| Type | Managed by | How it works |
|---|---|---|
| Managed | Replace the legacy ones. List or boolean parameters and support for Policy Simulator. E.g. iam.managed.disableServiceAccountCreation. | |
| Custom | Your organization | Allow or restrict creating and updating resources in supported services. Either enforced or not enforced. |
| Legacy managed | Previously called predefined. List rules (formerly list constraints) or boolean rules (formerly boolean constraints). |
List rules
Allow or deny a list of values. If you allow only certain values, everything else is implicitly denied. Prefixes:
is:exact value.under:the value and all its children (an organization, folder, or project ID).in:all resources that include the value, e.g.in:us-locationsingcp.resourceLocations.
Boolean rules
Enforced or not enforced. Example: enforcing compute.disableSerialPortAccess blocks serial port access. If the policy is set back to the Google-managed default, the constraint's default behavior applies.
Inheritance, dry run, and conditions
- Inheritance: descendants inherit the policy by default. A child resource can set its own policy that overrides inheritance or inherits the parent's. Policies with legacy constraints are merged according to hierarchy evaluation rules; managed constraints aren't merged: the child enforces the parent's as set or overrides it.
- Dry run: violations are audit-logged but not denied. Use it to measure impact before enforcing.
- Conditions with tags: a policy can apply only to resources with a specific tag, for example
environment=development. - Not retroactive (usually): if a resource already violates a new policy, it counts as a violation but the service doesn't stop; you fix it manually. Constraints that are enforced retroactively say so.
- Policy Intelligence: tools to simulate changes, test policies, and analyze which resources each one covers. Google recommends testing and dry-running every change.
Google Cloud security baseline
Organizations created on or after May 3, 2024 automatically get a bundle of enforced organization policies, because the open default configuration was vulnerable (for example, service account key creation).
| Policy | Constraint |
|---|---|
| Disable service account key creation | iam.managed.disableServiceAccountKeyCreation |
| Disable service account key upload | iam.disableServiceAccountKeyUpload |
| Prevent default service accounts from getting the Editor role | iam.automaticIamGrantsForDefaultServiceAccounts |
| Restrict identities by domain | iam.allowedPolicyMemberDomains |
| Restrict contacts by domain | essentialcontacts.managed.allowedContactDomains |
| Allow protocol forwarding for internal IPs only | compute.managed.restrictProtocolForwardingCreationForTypes |
| Uniform bucket-level access | storage.uniformBucketLevelAccess |
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID gcloud org-policies delete iam.allowedPolicyMemberDomains --organization=ORGANIZATION_ID
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| Projects must not disappear when the employee who created them leaves | Have an organization resource | Projects belong to the organization, not to the person. |
| Give the network team access to every network in the company with one grant | Grant the role at the organization | Roles are inherited by folders and projects. |
| Separate departments and delegate their administration | One folder per department | Folders act as sub-organizations. |
| Prevent resources from being created outside the EU | Organization policy with gcp.resourceLocations | Restricts the location of new resources. |
| Test a policy before enforcing it without blocking anyone | Dry-run mode | Violations are audit-logged but not denied. |
| Apply a restriction only to development resources | Conditional policy with tags | Enforced based on the resource tag. |
| Keep a custom project ID for future reuse | Delete the resources, not the project | A project ID can never be reused. |
| Recover a project shut down 10 days ago | Restore it | It stays in DELETE_REQUESTED for 30 days. |
Common exam traps
❓ Can you use folders without an organization resource?
No. Folders require an organization.
❓ Can the Organization Administrator create projects by default?
No. Following least privilege, it only manages IAM policies and sees the hierarchy. It needs additional roles, such as Project Creator or Folder Admin.
❓ Can you change a project ID?
No. The name can change; the ID is permanent and can't be reused, even after the project is deleted.
❓ Does a new organization policy stop resources that already violate it?
Usually not. It is recorded as a violation that you fix manually, except for constraints marked as retroactive.
❓ IAM or Organization Policy to stop everyone, owners included, from creating VMs with external IPs?
Organization Policy (compute.vmExternalIpAccess). IAM decides who; the organization policy decides which configurations are allowed.
❓ Are labels inherited like tags?
No. Tag bindings are inherited; labels aren't.
❓ Does a restored project get its billing account back?
Not automatically. You have to link it again.
Did you get this topic?
Test what you just learned
A company wants no project in its organization to be able to create resources outside the European Union, regardless of the IAM permissions of whoever tries. First it wants to see which workloads would be affected without blocking anything. What should it do?
Ready to test "Resource hierarchy and organization policies"?
Original questions, each with a full explanation.
Start a mock exam